Please quote some text from the message you’re replying to, so we know
what you’re referencing. It’s very hard to carry on discussions on a
mailing list if we have to guess which of the four (or, in along
thread, forty) posts you might be talking about. If your mailing makes
it to much of a pain to quote inline like I’m doing, you should at
least be able to “top-post”, to include part of the original message
below your reply.
I used the websites reply function actually to generate that message. I
replyed to my own thread since this was more like a side-effect that I
encountered, which resulted in the kind of behaviour you described.
What happens if you break this rule is exactly what you’re seeing. The
way Python ensures that doing `import spam` twice results in the same
spam module object (so your globals don’t all get duplicated) is by
storing modules by qualified name in sys.modules. So if the same file
has two different qualified names, it’s two separate modules.
I got that. That explains the behaviour I got, where Enum-Entries
suddenly where unequal to the "same" Enum-Entries causing a crash. Which
actually was better than having this behaviour happening unseen and
having the supposed same thing multiple times. That would have resulted
in two differen EventQueues. Cannot imagine all the time I would have
spent until I would have realized having two of them suddenly ;)
Is there a reasoning for that behavior of Python? I am watching from
outside and I know its always easy to say this is strange while there
might be legit reasoning behind that. The thing is: From the point of
the user the fact that importing the very same thing two times resulting
in different realizations thereof is as counter-intuitive as it gets.
Its a bit like driving home coming from a different street than normal
brings me in a house that is my house but is not my house ;) To
simplify: Why a thing isn't equal when its physically the same thing,
meaning the checksum is the same or its the same absolute path or ....
I hope that message ends up where it should. Have no idea, will just
send it and see what happens ;)
And thanks for all your patience and all the time reading and answering.
It helps me out. I will go with setup.py's in development mode for that
thing. Brings me almost to the same,and removes the local git submodules
I have currently.
Am 29.10.2019 um 17:16 schrieb Andrew Barnert:
On Oct 29, 2019, at 07:54, mer...@gmx.net <mailto:mer...@gmx.net> wrote:
I noticed some different (strange) behaviour when handling projects
like that.
Please quote some text from the message you’re replying to, so we know
what you’re referencing. It’s very hard to carry on discussions on a
mailing list if we have to guess which of the four (or, in along
thread, forty) posts you might be talking about. If your mailing makes
it to much of a pain to quote inline like I’m doing, you should at
least be able to “top-post”, to include part of the original message
below your reply.
Imagine following folder structure
# project_folder
# a_submodule
* a.py
* b.py
* __init__.py
* main.py
- content a.py:
class Foo:
pass
- content b.py:
from a import Foo
foo = Foo()
content main.py:
from os.path import join as pjoin
import os
import sys
# put a_submodule into path
curr_dir = os.path.abspath(os.path.dirname(__file__))
sys.path.append(pjoin(curr_dir, 'a_submodule'))
This is your problem. Never put a package on your sys.path, only put
the directory containing the package on it.
What happens if you break this rule is exactly what you’re seeing. The
way Python ensures that doing `import spam` twice results in the same
spam module object (so your globals don’t all get duplicated) is by
storing modules by qualified name in sys.modules. So if the same file
has two different qualified names, it’s two separate modules.
This also means that if you do this:
import spam
spam1 = spam
del sys.modules['spam']
del spam
import spam
assert spam is spam1
… the assert will fail.
If you actually need this behavior for some reason, you usually want
to call importlib directly and avoid using the sys.modules cache. But
usually you don’t want this behavior.
See the docs on the import system
(https://docs.python.org/3/reference/import.html)for full details on
how this works. The docs for the importlib module are also helpful.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/7D6RPBSM6PXLHFGAZCNYNP7MFU3ZAEMS/
Code of Conduct: http://python.org/psf/codeofconduct/
