By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,215 Members | 1,920 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,215 IT Pros & Developers. It's quick & easy.

What do you call a class not intended to be instantiated

P: n/a
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
Sep 21 '08 #1
Share this Question
Share on Google+
44 Replies


P: n/a
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
<st***@remove-this-cybersource.com.auwrote:
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"
Sep 21 '08 #2

P: n/a
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
<st***@remove-this-cybersource.com.auwrote:
>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
Sep 21 '08 #3

P: n/a
On Mon, Sep 22, 2008 at 9:05 AM, Steven D'Aprano
<st***@remove-this-cybersource.com.auwrote:
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"
Sep 21 '08 #4

P: n/a
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
Sep 21 '08 #5

P: n/a
On Mon, Sep 22, 2008 at 9:39 AM, Calvin Spealman <ir********@gmail.comwrote:
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"
Sep 22 '08 #6

P: n/a
On Sep 21, 6:05*pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:
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
<st...@remove-this-cybersource.com.auwrote:
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?
Sep 22 '08 #7

P: n/a
Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:
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.
Classes aren't designed to keep state; state is kept in instances.

I think you want Alex Martelli's 'Borg' pattern
<URL:http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66531>,
which is a class where each instance shares the same state.

--
\ “Pinky, are you pondering what I'm pondering?” “I think so, |
`\ Brain, but there's still a bug stuck in here from last time.” |
_o__) —_Pinky and The Brain_ |
Ben Finney
Sep 22 '08 #8

P: n/a
On Sep 21, 4:39*pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:
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*.
Sep 22 '08 #9

P: n/a
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 ?

Sep 22 '08 #10

P: n/a
On Mon, 22 Sep 2008 10:12:38 +1000, James Mills wrote:
On Mon, Sep 22, 2008 at 9:39 AM, Calvin Spealman <ir********@gmail.com>
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
Sep 22 '08 #11

P: n/a

Steven D'Aprano <st****@REMOVE.THIS.cybersource.com.auwrites:
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.
This:

Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:
Essentially, the class is used as a function that keeps state from
one call to the next.
Perhaps if you say what you want that isn't provided by any of a
function, a module, or a class. Specifically, what state you want to
track, and why it's so important that the state not be available to
the instances.

--
\ “I love and treasure individuals as I meet them, I loathe and |
`\ despise the groups they identify with and belong to.” —George |
_o__) Carlin, 2007 |
Ben Finney
Sep 22 '08 #12

P: n/a
On Mon, 22 Sep 2008 10:11:58 +0200, Bruno Desthuilliers wrote:
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.

I really don't know why everyone thinks I want a Singleton. I want to
uncouple objects, not increase the coupling.
Consider a factory function:

def factory(x): # a toy example
alist = [x]
def foo():
return alist
return foo
Now suppose we "instantiate" the factory (for lack of a better term):
>>f1 = factory(0)
f2 = factory(0)
Even though f1 and f2 have the same behaviour, they are obviously not the
same object. And although both return a list [0], it is not the same list:
>>f1() == f2() == [0]
True
>>f1() is f2()
False
They have a (very little) amount of state, which is *not* shared:
>>L = f1()
L.append(1)
f1()
[0, 1]
>>f2()
[0]
But there's only a limited amount of state that functions carry around. I
can give them more state like this:
>>f1.attr = 'x'
but it isn't good enough if the function needs to refer to it's own
state, because functions can only refer to themselves by name and the
factory can't know what name the function will be bound to.

As far as I know, the only objects that know how to refer to themselves
no matter what name they have are classes and instances. And instances
share at least some state, by virtue of having the same class.

(Pedants will argue that classes also share state, by virtue of having
the same metaclass. Maybe so, but that's at a deep enough level that I
don't care.)

I'm now leaning towards just having factory() instantiate the class and
return the instance, instead of having to do metaclass chicanery. Because
the class is built anew each time by the factory, two such instances
aren't actually sharing the same class. I think that will reduce
confusion all round (including mine!).

Hopefully now that I've explained what I want in more detail, it won't
seem so bizarre. Factory functions do it all the time. Is there a name
for this pattern?

Thanks to everyone who commented, your comments helped me reason out a
better alternative to what I first suggested.

--
Steven
Sep 22 '08 #13

P: n/a
On 22 Sep 2008 09:07:43 GMT, Steven D'Aprano
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.
Snce when are "users" ever involved
in programming problems or programming
languages ?

--JamesMills

--
--
-- "Problems are solved by method"
Sep 22 '08 #14

P: n/a
Steven D'Aprano a écrit :
On Mon, 22 Sep 2008 10:11:58 +0200, Bruno Desthuilliers wrote:
>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.


I really don't know why everyone thinks I want a Singleton.
May I quote you ?
"""
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.
"""
I want to
uncouple objects, not increase the coupling.
Consider a factory function:

def factory(x): # a toy example
alist = [x]
def foo():
return alist
return foo
Now suppose we "instantiate" the factory (for lack of a better term):
>>>f1 = factory(0)
f2 = factory(0)

Even though f1 and f2 have the same behaviour, they are obviously not the
same object. And although both return a list [0], it is not the same list:
>>>f1() == f2() == [0]
True
>>>f1() is f2()
False
They have a (very little) amount of state, which is *not* shared:
>>>L = f1()
L.append(1)
f1()
[0, 1]
>>>f2()
[0]
But there's only a limited amount of state that functions carry around. I
can give them more state like this:
>>>f1.attr = 'x'

but it isn't good enough if the function needs to refer to it's own
state, because functions can only refer to themselves by name and the
factory can't know what name the function will be bound to.
Then define your own callable type.
As far as I know, the only objects that know how to refer to themselves
no matter what name they have are classes and instances. And instances
share at least some state, by virtue of having the same class.
Is that a problem in your use case, and if so, why ???
(Pedants will argue that classes also share state, by virtue of having
the same metaclass. Maybe so, but that's at a deep enough level that I
don't care.)

I'm now leaning towards just having factory() instantiate the class and
return the instance, instead of having to do metaclass chicanery. Because
the class is built anew each time by the factory, two such instances
aren't actually sharing the same class. I think that will reduce
confusion all round (including mine!).

Hopefully now that I've explained what I want in more detail, it won't
seem so bizarre. Factory functions do it all the time. Is there a name
for this pattern?

Thanks to everyone who commented, your comments helped me reason out a
better alternative to what I first suggested.
Glad to know you found something helpful in all these answers, but as
far as I'm concerned, I'm afraid I still fail to understand what exactly
you're after...
Sep 22 '08 #15

P: n/a
2008/9/22 Bruno Desthuilliers <br********************@websiteburo.invalid>:
Steven D'Aprano a crit :
>>
On Mon, 22 Sep 2008 10:11:58 +0200, Bruno Desthuilliers wrote:
>>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.
Sounds to me like a functor, aka a function object:
http://en.wikipedia.org/wiki/Function_object

--
Tim Rowe
Sep 22 '08 #16

P: n/a
Tim Rowe a crit :
2008/9/22 Bruno Desthuilliers <br********************@websiteburo.invalid>:
>Steven D'Aprano a crit :
>>On Mon, 22 Sep 2008 10:11:58 +0200, Bruno Desthuilliers wrote:

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.

Sounds to me like a functor, aka a function object:
http://en.wikipedia.org/wiki/Function_object
Ok, then the simple solution is to implement a callable type (__call__
method), possibly with appropriate support for the descriptor protocol
if it's meant to be usable as a method.

Sep 22 '08 #17

P: n/a
On 22 Sep, 10:32, Steven D'Aprano
<ste...@REMOVE.THIS.cybersource.com.auwrote:
but it isn't good enough if the function needs to refer to it's own
state, because functions can only refer to themselves by name and the
factory can't know what name the function will be bound to.

As far as I know, the only objects that know how to refer to themselves
no matter what name they have are classes and instances. And instances
share at least some state, by virtue of having the same class.
Here is a simple way to make a function able to refer to its own
state:

def bindfunction(f):
def bound_f(*args, **kwargs):
return f(bound_f, *args, **kwargs)
bound_f.__name__ = f.__name__
return bound_f
>>@bindfunction
.... def foo(me, x):
.... me.attr.append(x)
.... return me.attr
....
>>foo.attr = []
foo(3)
[3]
>>foo(5)
[3, 5]
>>>
--
Arnaud
Sep 22 '08 #18

P: n/a
2008/9/22 Bruno Desthuilliers <br********************@websiteburo.invalid>:
>Sounds to me like a functor, aka a function object:
http://en.wikipedia.org/wiki/Function_object

Ok, then the simple solution is to implement a callable type (__call__
method), possibly with appropriate support for the descriptor protocol if
it's meant to be usable as a method.
Yes -- and instantiate the thing and keep the state in the instance,
rather than keeping the state in the class, so that it's possible to
safely have more than one of them if a later design change calls for
it (probably what led people off onto the sidetrack of thinking a
singleton was called for). That's the classic way of implementing a
"class [to be] used as a function".

--
Tim Rowe
Sep 22 '08 #19

P: n/a
On Sep 22, 8:45*am, "Tim Rowe" <digi...@gmail.comwrote:
2008/9/22 Bruno Desthuilliers <bruno.42.desthuilli...@websiteburo.invalid>:
Sounds to me like a functor, aka a function object:
http://en.wikipedia.org/wiki/Function_object
Ok, then the simple solution is to implement a callable type (__call__
method), possibly with appropriate support for the descriptor protocol if
it's meant to be usable as a method.

Yes -- and instantiate the thing and keep the state in the instance,
rather than keeping the state in the class, so that it's possible to
safely have more than one of them if a later design change calls for
it (probably what led people off onto the sidetrack of thinking a
singleton was called for). *That's the classic way of implementing a
"class [to be] used as a function".

--
Tim Rowe
I think you are either looking for a class that has a generator, or a
generator that has a reference to itself.
Sep 22 '08 #20

P: n/a
On Sep 21, 3:39*pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:
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
It actually sounds like you are doing something similar to the
monostate pattern. In Java the monostate pattern is usually
implemented by creating a class that only has static functions and
variables. You _can_ instantiate it, but every instance will share the
same state. In that way it is very similar to the Singleton pattern
(http://en.wikipedia.org/wiki/Singleton_pattern).

In Python I haven't found a need for monostate, since you can override
__new__ and return exactly the same instance. However, you you wanted
to be able to inherit a monostate object and share some of the state
between the class and subclass it might still be useful.

Perhaps if you post some example code?

Matt
Sep 22 '08 #21

P: n/a
Steven D'Aprano wrote:
>
Consider a factory function:

def factory(x): # a toy example
alist = [x]
def foo():
return alist
return foo
Now suppose we "instantiate" the factory (for lack of a better term):
>>>f1 = factory(0)
f2 = factory(0)
Your factory is returning closures. This is the functional equivalent
of a class returning instances.

class factory(object):
def __init__(self, x):
self.alist = [x]
def __call__(self):
return self.alist
Even though f1 and f2 have the same behaviour, they are obviously not the
same object. And although both return a list [0], it is not the same list:
>>>f1() == f2() == [0]
True
>>>f1() is f2()
False
same results
They have a (very little) amount of state, which is *not* shared:
>>>L = f1()
L.append(1)
f1()
[0, 1]
>>>f2()
[0]
same results
But there's only a limited amount of state that functions carry around.
That is why Python has class statements.
And instances share at least some state, by virtue of having the same
class.

If the only class attributes are methods and you do mutate the class,
then the fact that f1.__class__ is f2.__class__ is not really shared state.

[from a later post]
>But that's precisely what I want to avoid: I don't want the objects to
share *any* state, not even their class.

Unless you can show how sharing an immutable __class__ attribute is an
actual impediment, this strike me as artificial pedantry and unnecessary
self handcuffing. And you obviously can make that attribute effectively
immutable by ignoring it and also not changing the class itself. It is
just internal, implementation-defined bookkeeping.

The identity of immutable objects is irrelevant. If part of your
'unshared state' for each instance were a string, and two instances
happened to have the same string value, would you be upset because the
interpreter happened to use the same string object instead of two string
objects with the same value? Ditto for numbers, tuples, and so on.

Terry Jan Reedy

Sep 22 '08 #22

P: n/a
On Sep 22, 2:38*pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:
Aaron "Castironpi" Brady a crit :
On Sep 22, 8:45 am, "Tim Rowe" <digi...@gmail.comwrote:
2008/9/22 Bruno Desthuilliers <bruno.42.desthuilli...@websiteburo.invalid>:
>>Sounds to me like a functor, aka a function object:
http://en.wikipedia.org/wiki/Function_object
Ok, then the simple solution is to implement a callable type (__call__
method), possibly with appropriate support for the descriptor protocol if
it's meant to be usable as a method.
Yes -- and instantiate the thing and keep the state in the instance,
rather than keeping the state in the class, so that it's possible to
safely have more than one of them if a later design change calls for
it (probably what led people off onto the sidetrack of thinking a
singleton was called for). *That's the classic way of implementing a
"class [to be] used as a function".
--
Tim Rowe
I think you are either looking for a class that has a generator, or a
generator that has a reference to itself.

???

Going back to robot-mode, Aaron ?
Not getting the same sense of "soul" as from my usual posts. I guess
so. Might even drop the name change, too... while I'm at it. One
more word from you about it and I'm starting a thread, and calling it,
"Python and my sense of 'soul'". Ha ha.
Sep 22 '08 #23

P: n/a
On Sep 22, 3:28*pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:
Aaron "Castironpi" Brady a crit :
On Sep 22, 2:38 pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.frwrote:
(snip)
Going back to robot-mode, Aaron ?
Not getting the same sense of "soul" as from my usual posts. *I guess
so. *Might even drop the name change, too...

Don't !-)
while I'm at it. *One
more word from you about it *and I'm starting a thread, and calling it,
"Python and my sense of 'soul'". *Ha ha.

Please bear with me - and understand that the above half-backed
half-joke was also an implicit aknowledgement of the recent changes in
your mode of communication. I should have added a <wink>, I think...
I can attribute it to a change in environment. Going "back" to robot
mode would imply one wasn't always in it, and as such I interpreted a
tacit compliment. Thank you for the compliment, Bruno. I don't
suppose "starting a thread" is much of a threat, after all... at least
in isolation.

Regardless, as I've stated, I find the feedback valuable that there
seems (to people) to be more than one context that I'm writing from,
and I appreciate the chance to learn about it. It's an observation an
erst friend made once that one can never perceive oneself directly.
(Whether that's a virtue depends on what difference there is between
self-conscious, and self-aware.)
Sep 22 '08 #24

P: n/a
On Mon, 22 Sep 2008 19:41:46 +1000, James Mills wrote:
On 22 Sep 2008 09:07:43 GMT, Steven D'Aprano
>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.

Snce when are "users" ever involved
in programming problems or programming languages ?
What an astounding question.

Consider a class. There are the programmers who write the class, and
there are the programmers (possibly the same people, but not necessarily)
who use the class. The second set of people, the programmers who use the
class, are *users* of the class. What else would they be?

--
Steven
Sep 22 '08 #25

P: n/a
On Sep 22, 5:32*pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:
On Mon, 22 Sep 2008 19:41:46 +1000, James Mills wrote:
On 22 Sep 2008 09:07:43 GMT, Steven D'Aprano
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.
Snce when are "users" ever involved
in programming problems or programming languages ?

What an astounding question.

Consider a class. There are the programmers who write the class, and
there are the programmers (possibly the same people, but not necessarily)
who use the class. The second set of people, the programmers who use the
class, are *users* of the class. What else would they be?

--
Steven
Usegrammers?
Sep 22 '08 #26

P: n/a
On Sep 22, 11:46*pm, "Aaron \"Castironpi\" Brady"
<castiro...@gmail.comwrote:
On Sep 22, 5:32*pm, Steven D'Aprano <st...@REMOVE-THIS-

cybersource.com.auwrote:
On Mon, 22 Sep 2008 19:41:46 +1000, James Mills wrote:
On 22 Sep 2008 09:07:43 GMT, Steven D'Aprano
>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.
Snce when are "users" ever involved
in programming problems or programming languages ?
What an astounding question.
Consider a class. There are the programmers who write the class, and
there are the programmers (possibly the same people, but not necessarily)
who use the class. The second set of people, the programmers who use the
class, are *users* of the class. What else would they be?
--
Steven

Usegrammers?
And professionals are programmers, amateurs are amgrammers and newbies
are newgrammers? :-)
Sep 23 '08 #27

P: n/a
On Sep 22, 6:55*pm, MRAB <goo...@mrabarnett.plus.comwrote:
On Sep 22, 11:46*pm, "Aaron \"Castironpi\" Brady"

<castiro...@gmail.comwrote:
On Sep 22, 5:32*pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:
On Mon, 22 Sep 2008 19:41:46 +1000, James Mills wrote:
On 22 Sep 2008 09:07:43 GMT, Steven D'Aprano
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.
Snce when are "users" ever involved
in programming problems or programming languages ?
What an astounding question.
Consider a class. There are the programmers who write the class, and
there are the programmers (possibly the same people, but not necessarily)
who use the class. The second set of people, the programmers who use the
class, are *users* of the class. What else would they be?
--
Steven
Usegrammers?

And professionals are programmers, amateurs are amgrammers and newbies
are newgrammers? :-)
Not to be rude, but no. Usegrammers usegram.
Sep 23 '08 #28

P: n/a
Snce when are "users" ever involved
in programming problems or programming
languages ?
since the begining, the first users are programmers, users of your
libraries.
Sep 23 '08 #29

P: n/a
Usegrammers?
>
usegrammers are just those that use grammars, but misspell it.
Sep 23 '08 #30

P: n/a
In article <y9******************************@earthlink.com> ,
Dennis Lee Bieber <wl*****@ix.netcom.comwrote:
>On 21 Sep 2008 22:39:47 GMT, Steven D'Aprano
<st***@REMOVE-THIS-cybersource.com.audeclaimed the following in
comp.lang.python:
>>
What do you call such a class?

A wasted definition... The same functionality is achieved by just
creating and importing a module. Your "class methods" would just be
functions within the module; class level attributes would be module
level objects (access with global if writing to them, use a _ to
indicate "internal")
Seems to me that if all the module is used for is to store state, you're
wasting a file on disk. I personally prefer to use a class singleton.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"Argue for your limitations, and sure enough they're yours." --Richard Bach
Sep 26 '08 #31

P: n/a
On Thu, 25 Sep 2008 21:17:14 -0700, Aahz wrote:
Seems to me that if all the module is used for is to store state, you're
wasting a file on disk. I personally prefer to use a class singleton.
I don't recognise the term "class singleton". Can you explain please? How
is it different from an ordinary singleton?

For the record, I ended up deciding that I didn't need any special
objects or metaclass programming, just a factory function which returned
a regular instance. But reading the thread has been a good education for
me, thanks folks.
--
Steven
Sep 26 '08 #32

P: n/a
In article <pa*********************@REMOVE.THIS.cybersource.c om.au>,
Steven D'Aprano <st****@REMOVE.THIS.cybersource.com.auwrote:
>On Thu, 25 Sep 2008 21:17:14 -0700, Aahz wrote:
>>
Seems to me that if all the module is used for is to store state, you're
wasting a file on disk. I personally prefer to use a class singleton.

I don't recognise the term "class singleton". Can you explain please? How
is it different from an ordinary singleton?
An ordinary singleton is instantiating the class multiple times yet
returning the same instance object; a class singleton is simply using
the class directly (like a module).
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"Argue for your limitations, and sure enough they're yours." --Richard Bach
Sep 27 '08 #33

P: n/a
On Fri, 26 Sep 2008 22:15:43 -0700, Aahz wrote:
In article <pa*********************@REMOVE.THIS.cybersource.c om.au>,
Steven D'Aprano <st****@REMOVE.THIS.cybersource.com.auwrote:
>>On Thu, 25 Sep 2008 21:17:14 -0700, Aahz wrote:
>>>
Seems to me that if all the module is used for is to store state,
you're wasting a file on disk. I personally prefer to use a class
singleton.

I don't recognise the term "class singleton". Can you explain please?
How is it different from an ordinary singleton?

An ordinary singleton is instantiating the class multiple times yet
returning the same instance object; a class singleton is simply using
the class directly (like a module).
Amazing. That's *exactly* what I was thinking of when I first asked my
question.

Since I now no longer think I need such a beast, this is just academic
curiosity, but given a class singleton, I'd like to be able to call it as
if it were a function. Normally calling a class object returns an
instance -- I wish to return something else. Is that just a matter of
overriding __new__?

This seems to works:
>>class ClassSingleton(object):
.... thing = (0, 1, 2)
.... def __new__(cls, *args):
.... return len(args+cls.thing)
....
>>ClassSingleton(1, 2, 4, 8, 16)
8

Is it really that easy?

--
Steven
Sep 27 '08 #34

P: n/a
Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:
On Fri, 26 Sep 2008 22:15:43 -0700, Aahz wrote:
An ordinary singleton is instantiating the class multiple times
yet returning the same instance object; a class singleton is
simply using the class directly (like a module).
Where is this "class singleton" terminology from? It seems redundant
to me. It also doesn't seem to have anything to do with what
"singleton" means as a pattern; "using a class" is simply using a
class.
Since I now no longer think I need such a beast
That's a relief :-)
I'd like to be able to call [a class] as if it were a function.
Normally calling a class object returns an instance -- I wish to
return something else.
In that case, you *don't* want a class at all; the entire point of a
class is to define behaviour for instances.

Instead, you want to define a class whose *instances* are callable, by
defining the '__call__' method to do whatever it is you want.
This seems to works:
>class ClassSingleton(object):
... thing = (0, 1, 2)
... def __new__(cls, *args):
... return len(args+cls.thing)
...
>ClassSingleton(1, 2, 4, 8, 16)
8
Horribly obfuscatory. Calling a class should return a new instance of
the class or something like it.

Instead, define it so the user instantiates the class by calling the
class, and *then* calls that non-class object, and so shouldn't expect
to get a new instance back:
>>class CallableAppendor(object):
... thing = (0, 1, 2)
... def __call__(self, *args):
... return len(args + self.thing)
...
>>appendor = CallableAppendor()
appendor(1, 2, 4, 8, 16)
8

--
\ “Pleasure's a sin, and sometimes sin's a pleasure.” —“Lord” |
`\ George Gordon Noel Byron, _Don Juan_ |
_o__) |
Ben Finney
Sep 27 '08 #35

P: n/a
On Sat, 27 Sep 2008 18:20:17 +1000, Ben Finney wrote:
Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:
>On Fri, 26 Sep 2008 22:15:43 -0700, Aahz wrote:
An ordinary singleton is instantiating the class multiple times yet
returning the same instance object; a class singleton is simply using
the class directly (like a module).

Where is this "class singleton" terminology from?
I don't know. Googling on it brings up an awful lot of C++ and Java
source code for regular Singletons. Perhaps Aahz can shed some light on
it?

It seems redundant to
me. It also doesn't seem to have anything to do with what "singleton"
means as a pattern; "using a class" is simply using a class.

I don't see why this idiom causes such conceptual difficulty. There are
classes with many instances; there are classes with a single instance
(Singleton). Why should't there be classes with no instances?

A class is just an object. If you find yourself caring whether a
particular object is a class, an instance or a function, then you have to
ask yourself why you are worrying about the implementation details. Of
course as the library writer, it's your job to worry about the
implementation details, but ideally the library user shouldn't have to.

>Since I now no longer think I need such a beast

That's a relief :-)
>I'd like to be able to call [a class] as if it were a function.
Normally calling a class object returns an instance -- I wish to return
something else.

In that case, you *don't* want a class at all; the entire point of a
class is to define behaviour for instances.
Classes encapsulate state + behaviour in one package, and they allow
inheritance. That's a lot more than merely defining behaviour of
instances. Instances in turn have the additional capability of being able
to over-ride the class' state and behaviour:

class C(object):
x = 'spam'

c = C()
c.x = 'ham' # doesn't touch C.x

If your instance doesn't do something the class can't do on it's own, why
bother with the instance?
Instead, you want to define a class whose *instances* are callable, by
defining the '__call__' method to do whatever it is you want.
Most of the time, sure.
>This seems to works:
>>class ClassSingleton(object):
... thing = (0, 1, 2)
... def __new__(cls, *args):
... return len(args+cls.thing) ...
>>ClassSingleton(1, 2, 4, 8, 16)
8

Horribly obfuscatory. Calling a class should return a new instance of
the class or something like it.
Apart from the name, which I dislike, what is obfuscatory about it?
Haven't you ever used factory functions or class builders? It's the same
principle. Why do you care that ClassSingleton is a class instead of a
function?

I'm certainly not saying that we should use classes this way all the
time, but the capability is there, and apparently not by accident. Guido
wrote:

"__new__ must return an object. There's nothing that requires that it
return a new object that is an instance of its class argument, although
that is the convention. If you return an existing object of your class or
a subclass, the constructor call will still call its __init__ method. If
you return an object of a different class, its __init__ method will not
be called."

http://www.python.org/download/relea....3/descrintro/
Instead, define it so the user instantiates the class by calling the
class, and *then* calls that non-class object, and so shouldn't expect
to get a new instance back:
>>class CallableAppendor(object):
... thing = (0, 1, 2)
... def __call__(self, *args):
... return len(args + self.thing) ...
>>appendor = CallableAppendor()
>>appendor(1, 2, 4, 8, 16)
8

That's the right solution when the instance is able to override the state
and/or behaviour of the class. Most uses of classes are like that:

class Spam(object):
def __init__(self, n):
self.n = n
def sing(self):
return "spam "*self.n + " glorious SPAM!!!"

Because the behaviour (method 'sing') depends on state which is specific
to the instance (attribute 'n'), it is right and proper to instantiate
the class. The class 'Spam' is a constructor for instances, and the
instances do all the work.

But my earlier example is not the same. In the example I gave, neither
the behaviour nor the state depend on the instance: everything is
specified in the class. Ben's variant behaves differently: the caller
might override appendor.thing by hand. That is Ben's choice, of course,
and it may be a valid one for many applications, but it's displaying
different behaviour to my example.

In my example, the instance doesn't matter. I could write it like this:
>>class CallableAppendor(object):
.... thing = (0, 1, 2)
.... @classmethod
.... def __call__(cls, *args):
.... return len(args + cls.thing)
....
>>appendor = CallableAppendor()
appendor.thing = (1, 2, 3, 4, 5, 6, 7, 8)
appendor(1, 2, 4, 8, 16)
8
>>CallableAppendor.__call__(1,2,4,8,16)
8

but what's the purpose of instantiating the class?
I concede that this is a made-up example, but here's an actual practical
example of a class with no instances: Guido's attempt at an Enum:

"This (ab)uses the class syntax as an elegant way to define enumerated
types. The resulting classes are never instantiated -- rather, their
class attributes are the enumerated values. For example:
class Color(Enum):
red = 1
green = 2
blue = 3
print Color.red

will print the string ``Color.red'', while ``Color.red==1'' is true, and
``Color.red + 1'' raise a TypeError exception."

http://www.python.org/doc/essays/metaclasses/


--
Steven
Sep 27 '08 #36

P: n/a
On Sep 27, 5:33*am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:
On Sat, 27 Sep 2008 18:20:17 +1000, Ben Finney wrote:
Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.auwrites:
On Fri, 26 Sep 2008 22:15:43 -0700, Aahz wrote:
An ordinary singleton is instantiating the class multiple times yet
returning the same instance object; a class singleton is simply using
the class directly (like a module).
Where is this "class singleton" terminology from?

I don't know. Googling on it brings up an awful lot of C++ and Java
source code for regular Singletons. Perhaps Aahz can shed some light on
it?
[snip]
In my example, the instance doesn't matter. I could write it like this:
>class CallableAppendor(object):

... * * thing = (0, 1, 2)
... * * @classmethod
... * * def __call__(cls, *args):
... * * * * return len(args + cls.thing)
...>>appendor = CallableAppendor()
>appendor.thing = (1, 2, 3, 4, 5, 6, 7, 8)
appendor(1, 2, 4, 8, 16)
8
>CallableAppendor.__call__(1,2,4,8,16)

8

but what's the purpose of instantiating the class?
I've used them (class singletons, adopting the term) as a Globals
namespace, but only to the end of tidying. It makes it easy to
reassign immutables.

It is too bad 'CallableAppendor.__call__(1,2,4,8,16)' doesn't work as
expected. That is, 'CallableAppendor(1,2,4,8,16)' dosen't call
'__call__'. I have a workaround, which may be just what you're
looking for.
>>class A(type):
.... def __call__( self, *ar ):
.... print 'call', self, ar
....
>>class B(object):
.... __metaclass__= A
....
>>B(3)
call <class '__main__.B'(3,)

Overriding the __call__ method of 'type' has the effect of giving you
a static __call__ method on a class-- a method which doesn't need an
instance to call. Your behavior may be counterintuitive though, to
someone who wants to instantiate 'B', in this case, and proceed like a
normal object. That is, they want to call a generic class and use it,
and also expect instances of B to behave as B. You can't have both,
so either return B from B.__new__, or, to instantiate B, take the long
way and call B.__new__ directly.
>>B.__new__(B)
<__main__.B object at 0x009FDB70>

Has anyone stepped through the C code to find out when the decision is
made to call which function, B.__new__ or A.__call__, when B is
called? I'm happy that overriding type.__call__ produced the intended
results; it's always nice when things go right.
Sep 27 '08 #37

P: n/a
In article <87************@benfinney.id.au>,
Ben Finney <bi****************@benfinney.id.auwrote:
>Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:
>On Fri, 26 Sep 2008 22:15:43 -0700, Aahz wrote:
>>>
An ordinary singleton is instantiating the class multiple times
yet returning the same instance object; a class singleton is
simply using the class directly (like a module).

Where is this "class singleton" terminology from? It seems redundant
to me. It also doesn't seem to have anything to do with what
"singleton" means as a pattern; "using a class" is simply using a
class.
I don't remember where I picked it up, probably here some years ago.
The point of the terminology is to distinguish how the class is *used*,
in precise parallel with "module singleton".
>I'd like to be able to call [a class] as if it were a function.
Normally calling a class object returns an instance -- I wish to
return something else.

In that case, you *don't* want a class at all; the entire point of a
class is to define behaviour for instances.
Absolutely agreed with your first clause, disagreed about the second
clause. As I said earlier, the main point of a class singleton is to get
the effect of a module singleton without the need to create another file
on disk. In that case there is no instance and therefore the point of
the class is no longer to define behavior for instances.

But you can't call a module, and classes have well-defined behavior for
calling them, so you shouldn't try to pervert a class singleton by
defining behavior for calling them. In fact, I would recommend creating
an __init__() method that raises NotImplementedError precisely to prevent
this usage (or have a __new__() method that returns None, but I generally
prefer to recommend practices that work with classic classes).

One cute reason to prefer class singletons to module singletons is that
subclassing works well for creating multiple singletons. But really,
the main reason I use class singletons is that they are the absolute
simplest way to get attribute access:

class Foo: pass
Foo.bar = 'xyz'
if data == Foo.bar:
print "!"

Once it gets much more complicated than that, I prefer to use a smarter
object.
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

"Argue for your limitations, and sure enough they're yours." --Richard Bach
Sep 27 '08 #38

P: n/a
In article <gb**********@panix3.panix.com>, aa**@pythoncraft.com (Aahz)
wrote:
One cute reason to prefer class singletons to module singletons is that
subclassing works well for creating multiple singletons. But really,
the main reason I use class singletons is that they are the absolute
simplest way to get attribute access:

class Foo: pass
Foo.bar = 'xyz'
if data == Foo.bar:
print "!"
I've often done something similar, creating a dummy class:

class Data:
pass

just so I could create instances of it to hang attributes off of:

foo = Data()
foo.bar = 'xyz'

That's a trick I've been using since the Old Days (i.e. before new-style
classes came along). When I saw your example, my first thought was "That's
silly, now that there's new-style classes, you can just create an instance
of object!". Unfortunately, when I tried it, I discovered it didn't work.
You *can* instantiate object, but you don't get a class instance, so you
can't create attributes on it.
>>x = object()
type(x)
<type 'object'>
>>x.foo = 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'object' object has no attribute 'foo'
Sep 27 '08 #39

P: n/a
Aahz wrote:
In article <87************@benfinney.id.au>,
Ben Finney <bi****************@benfinney.id.auwrote:
>Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:
>>I'd like to be able to call [a class] as if it were a function.
Normally calling a class object returns an instance -- I wish to
return something else.
In that case, you *don't* want a class at all; the entire point of a
class is to define behaviour for instances.

Absolutely agreed with your first clause, disagreed about the second
clause. As I said earlier, the main point of a class singleton is to get
the effect of a module singleton without the need to create another file
on disk.
In 3.0, at least, one does not need a disk file to create a module.
>>import types
me = types.ModuleType('me') # type(__builtins__) works, no import
me
<module 'me' (built-in)>
>>me.a = 1
me.a
1
>>me.a + 1
2

That said, a blank class is even easier, and the representation is better.

tjr

Sep 27 '08 #40

P: n/a
Aaron "Castironpi" Brady wrote:
>>>class A(type):
... def __call__( self, *ar ):
... print 'call', self, ar
...
>>>class B(object):
... __metaclass__= A
...
>>>B(3)
call <class '__main__.B'(3,)

Overriding the __call__ method of 'type' has the effect of giving you
a static __call__ method on a class-- a method which doesn't need an
instance to call. Your behavior may be counterintuitive though, to
someone who wants to instantiate 'B', in this case, and proceed like a
normal object. That is, they want to call a generic class and use it,
and also expect instances of B to behave as B. You can't have both,
so either return B from B.__new__, or, to instantiate B, take the long
way and call B.__new__ directly.
>>>B.__new__(B)
<__main__.B object at 0x009FDB70>

Has anyone stepped through the C code to find out when the decision is
made to call which function, B.__new__ or A.__call__, when B is
called?
For Python coded objects, ob(*args) in code translates to internal
execution of type(ob).__call__(ob, *args) (without further
translation!). The interpreter compiles a statement at a time, without
looking back to do type inferencing, and so does not know what type is
being called or if it is even callable.

For B, B(*args) == type(B).__call__(B, *args) == A.__call__(B, *args).
So there is no decision.

For C coded objects, I believe ob(*args) in Python code translate to a C
call of the C equivalent of type(ob).tp_call (or something like that).
From observation, type.tp_call acts something like this:

def __call__(cls, *args):
if cls == type:
if len(*args):
return arg[0].__class__
elif len(*args) == 3:
return type.__new__(type, *args) # or maybe not pass type?
else:
raise TypeError('type() takes 1 or 3 arguments')
else:
return cls.__new__(cls, *args)

So, for a normal class C (an instance of type), type.__call__ calls
C.__new__.

Terry Jan Reedy
Sep 27 '08 #41

P: n/a
On Sep 27, 6:16*pm, Terry Reedy <tjre...@udel.eduwrote:
Aaron "Castironpi" Brady wrote:
>>class A(type):
... * * def __call__( self, *ar ):
... * * * * * * print 'call', self, ar
...
>>class B(object):
... * * __metaclass__= A
...
>>B(3)
call <class '__main__.B'(3,)
Overriding the __call__ method of 'type' has the effect of giving you
a static __call__ method on a class-- a method which doesn't need an
instance to call. *Your behavior may be counterintuitive though, to
someone who wants to instantiate 'B', in this case, and proceed like a
normal object. *That is, they want to call a generic class and use it,
and also expect instances of B to behave as B. *You can't have both,
so either return B from B.__new__, or, to instantiate B, take the long
way and call B.__new__ directly.
>>B.__new__(B)
<__main__.B object at 0x009FDB70>
Has anyone stepped through the C code to find out when the decision is
made to call which function, B.__new__ or A.__call__, when B is
called? *

For Python coded objects, ob(*args) in code translates to internal
execution of type(ob).__call__(ob, *args) (without further
translation!). *The interpreter compiles a statement at a time, without
looking back to do type inferencing, and so does not know what type is
being called or if it is even callable.

For B, B(*args) == type(B).__call__(B, *args) == A.__call__(B, *args).
So there is no decision.

For C coded objects, I believe ob(*args) in Python code translate to a C
call of the C equivalent of type(ob).tp_call (or something like that).
*From observation, type.tp_call acts something like this:

def __call__(cls, *args):
* *if cls == type:
* * *if len(*args):
* * * *return arg[0].__class__
* * *elif len(*args) == 3:
* * * *return type.__new__(type, *args) # or maybe not pass type?
* * *else:
* * * *raise TypeError('type() takes 1 or 3 arguments')
* *else:
* * *return cls.__new__(cls, *args)

So, for a normal class C (an instance of type), type.__call__ calls
C.__new__.

Terry Jan Reedy
Oh, I see. Then it's the class statement that calls type.__new__.

class A: ...
-A= type( 'A', ... )
-A= type.__call__( type, 'A', ... )
-A= type.__new__( type, 'A', ... )

Plus an iteration over the contents of 'namespace', to search for
properties that themselves have a __get__ method. And returns an
unboundmethod instance "of" it, for a value of "of" that's hard to
concentrate on. I jest.

Perhaps what Steven is looking for is a subclass of 'type' that does
not give this default behavior of 'unboundmethoding' everything it
can. That is, defaulting to 'staticmethod' or 'classmethod', and
perhaps offering a 'boundmethod' decorator for the exceptions.

For the case of '__call__', which he does want to control, that could
merely call B.__call__, instead of B.__new__. Untested:
>>class A(type):
.... def __call__( self, *ar ):
.... return self.__call__( *ar )

or

.... return self.__call__( self, *ar )

Which would come through to 'B' as:
>>class B(object):
.... __metaclass__= A
.... def __call__( cls, *ar ).

This is because self == B in the example. This makes me scowl. Very
odd.
Sep 27 '08 #42

P: n/a
On Sat, 27 Sep 2008 17:41:42 -0400, Terry Reedy wrote:
In 3.0, at least, one does not need a disk file to create a module.
>>import types
>>me = types.ModuleType('me') # type(__builtins__) works, no import
>>me
<module 'me' (built-in)>
>>me.a = 1
>>me.a
1
>>me.a + 1
2
Seems to work for Python 2.5 as well.

That said, a blank class is even easier, and the representation is
better.
And modules aren't callable. I've often thought they should be.
--
Steven
Sep 28 '08 #43

P: n/a
Steven D'Aprano wrote:
And modules aren't callable. I've often thought they should be.
Modules are not callable because their class, module, has no __call__
instance method. But (in 3.0, which is all I will check) you can
subclass module and add one.
>>m = type(__builtins__)
m
<class 'module'>
>>dir(m)
['__class__', '__delattr__', '__dict__', '__doc__', '__eq__',
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__',
'__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
'__subclasshook__']
>>class m2(m):
def __call__(self, *args, **kwds):
print(self, args, kwds)

>>mod = m2('mod') # only arg required by module.__init__
mod(1,2,3,a=4,b=5)
<module 'mod' (built-in)(1, 2, 3) {'a': 4, 'b': 5}
>>mod # did not override __repr__
<module 'mod' (built-in)>

So, roll your own to your taste.

Terry Jan Reedy

Sep 28 '08 #44

P: n/a
Terry Reedy <tj*****@udel.eduwrites:
Steven D'Aprano wrote:
And modules aren't callable. I've often thought they should be.

Modules are not callable because their class, module, has no
__call__ instance method. But (in 3.0, which is all I will check)
you can subclass module and add one.
Works fine in Python 2.5.2 also::

Python 2.5.2 (r252:60911, Aug 8 2008, 11:09:00)
[GCC 4.3.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>module = type(__builtins__)
module
<type 'module'>
>>'__call__' in dir(module)
False
>>import sys
class CallableModule(module):
... def __call__(self, *args, **kwargs):
... sys.stdout.write("%(self)r, %(args)r, %(kwargs)r\n" % vars())
...
>>'__call__' in dir(CallableModule)
True
>>foo = CallableModule('foo')
foo(1, 2, 3, a=4, b=5)
<module 'foo' (built-in)>, (1, 2, 3), {'a': 4, 'b': 5}
>>foo
<module 'foo' (built-in)>

--
\ “There are only two ways to live your life. One is as though |
`\ nothing is a miracle. The other is as if everything is.” |
_o__) —Albert Einstein |
Ben Finney
Sep 28 '08 #45

This discussion thread is closed

Replies have been disabled for this discussion.