What is a class?

[Gabriel Genellina]

En Thu, 06 Mar 2008 14:40:47 -0200, <castironpi at gmail.com> escribi�:

> On Mar 6, 12:17 am, "Daniel Fetchinson" <fetchin... at googlemail.com>
> wrote:
>>
>> > What does exec( open( 'modA.py' ).read() ) do?
>>
>
> A more appropriate formulation of the 'question behind the words'
> would have been, 'are there any weird corner cases in which it doesn't
> import modA?  I recognize it doesn't on .pyc and .pyd files, but you
> could say exec( open( 'modA.py' ).read() ) ==> import modA, even if
> import modA =!=> exec( open( 'modA.py' ).read() ) all the time.

Then write the question that way. Working crystall balls are hard to find  
nowadays...

They're different; no module object is created by the exec statement.
When the import machinery determines that certain module isn't already  
loaded, and that the .py version has to be used, it does something like  
this:

newmodule = sys.modules[modulename] = ModuleType(modulename)
# constructor sets __name__ and a null __doc__
newmodule.__builtins__ = current builtins
newmodule.__file__ = filename
code = read from filename and compile it
exec code in newmodule.__dict__

> However, a way of asking that's more direct would have been, "Wait...
> can't you create multiple module instances like that?", but since
> we've already seen successful loadings of at least the builtins,
> that's been treated.

There are ways to create many instances of the same module, but not using  
a plain import statement, or using the API in the intended way.

> Maybe you even hear the right thing if I say,
> "Does exec( open( 'modA.py' ).read() ) do the things of import modA?"

Only in part, as you can see above.

> Yes, I can read the docs, but no, I can't check every possible
> combination of modules.
> The idea behind a singleton is to ensure something.  You want non-
> primary instances impossible to create.  However, if (wording got
> tangled here) for singleton A, if class B does the same thing, just
> has different allocations-- it's own-- then A is still a singleton.
> The writer of B hasn't defeated or contradicted the letter or spirit
> of A.
>
> OP's question might have come from a variety of perspectives.  In some
> ways yes, in others no.  That is, if you try to reinstantiate modA,
> you get the same instance.  But if you try really hard, you get a new
> one.  Are you looking for an extension to import modA that won't
> return an instance that is old?
>
> So far, I know this: modules and classes are both namespaces.  Are
> those singletons?

Strictly speaking, neither classes nor modules are singletons; classes are  
instances of type, and modules are instances of their type, and there are  
many instances of each. We can consider "qualified singletons", where we  
want to have a single instance of a class given certain attributes.

In that sense, modules are "named" singletons; Python tries to ensure  
that, given a module name, the module object returned is always the same  
one - even if you spell the name in different ways. The import statement,  
the __import__ builtin, the imp module, the PyImport_AddModule C function,  
all of them try to ensure that. Of course there are ways to shoot yourself  
in the foot -by example, creating a new module "in the fly" with  
PyModule_New-

On the contrary, classes have no such restrictions. Of course, for classes  
defined at the global level in a module, you can't have two of them with  
the same name, but that's just because the module namespace can't hold two  
values for a single name. But you can create classes dinamically, or  
define them inside a function, or... lots of ways of creating many  
instances of the "same" class, and Python won't enforce them to be always  
the same object.

So, I'd say that modules are named singletons, and classes aren't  
singletons at all.

-- 
Gabriel Genellina