C
Carl Banks
"His" posts?
Carl Banks
"His" posts?
Carl Banks
B
Bruno Desthuilliers
(e-mail address removed) a écrit :
RTFM
RTFM
C
castironpi
Thanks for the reference. I'm basically experienced with Python, but
I may read there too.
I asked the question mostly rhetorically. <simile> Like when people
ask, who cares, or who knows. They don't want the answer---- unless
there is one. </simile>
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.
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. Maybe you even hear the right thing if I say,
"Does exec( open( 'modA.py' ).read() ) do the things of import modA?"
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?
D
D'Arcy J.M. Cain
Whatever. I'm too old to worry about searching for politically correct,
gender neutral pronouns.
D
D'Arcy J.M. Cain
Actually, I am reading this as a mailing list and since I run Unix and
procmail I am sure that I could set something up if it really starts to
be annoying. So far the simple filters deal with all but a smattering
of problem postings so I don't need to expend the time.
C
Carl Banks
I'm pretty sure even the most PC people wouldn't suggest using a
masculine pronoun for an inanimate objects.
(Ok, some probably would.)
Carl Banks
C
castironpi
The Google Groups reader doesn't always let you see new replies to
really old messages, something they should change (this means you).
But there is an 'active old threads', but it doesn't catch every one.
I want to read those plonk.
C
castironpi
I'm talking about castironpi. I find his posts a waste of my time
Traceback (most recent call last):
Traceback (most recent call last):
J
johan.sanden
A class is a bag of stuff and a namespace
J.
C
castironpi
A class is a bag of stuff and a namespace
J.
A module is a bag of stuff and a namespace. Different stuff.
{ '__module__', '__weakref__'}
G
Gabriel Genellina
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__
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.
Only in part, as you can see above.
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.
G
Gabriel Genellina
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__
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.
Only in part, as you can see above.
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.
S
Steven D'Aprano
Yes, you could say that, but you'd be wrong. Please test your code before
making such claims in the future.
C
castironpi
Aye aye. -1 response not phrased in the form of a question.
Is it correct that exec( open( 'modA.py' ).read() ) -and- from modA
import * create "effectively" same results, such as in the remaning
program not checking __module__ attributes?
Is there a slight modification of both sides that does cover a non-
trivial volume of programs, such as maybe,
exec( open( 'modA.py' ).read(), locals= dict( __module__= 'modA' ) ) -
and- from modA import *, or something? I notice that
from toimp import *
f()
exec( open( 'toimp.py' ).read() )
f()
generate the same output so far.
S
Steven D'Aprano
All the words in that sentence are English, but as a whole it makes no
sense.
You're getting closer now. (By the way, exec is a statement, so you don't
need brackets around its arguments.)
exec open('modA.py').read()
gives *almost* the same results as
from modA import *
The differences I can think of:
(1) The exec version doesn't cache the results, so if you execute the
line repeatedly you will execute the same code over and over again,
possibly causing unexpected side-effects. import caches the results, and
so will be faster.
(2) The import version may read from modA.pyc, modA.pyo or modA.so even
if there is a modA.py file. The exec version can't import from anything
but modA.py.
(3) The exec version as written always puts the results in the global
scope, even if you execute it inside a function. (In the future, "from
modA import *" will be forbidden inside functions, but at the moment it
is still legal.)
(4) The exec version doesn't search sys.path for modA; import does.
(5) The exec version can't read modules inside a zip file; import can.
There may be other differences I haven't thought of.
Again, I don't understand what you are saying.
*Slight* modification, no.
I'm sure that with sufficient effort, you could add caching, search
sys.path, and look inside zip files. Those three things wouldn't be
horribly difficult, but it wouldn't be a one-liner -- off the top of my
head, I'd guess fifty to a hundred lines of code to re-invent those
particular wheels correctly.
However, recreating the rest of the import mechanism would be terribly
complicated. I'm not really sure it could be done. For example, how would
you deal with modules written in C from within Python? You'd need access
to Python internals that, as far as I know, aren't available.