I am a bit confused as to why simply commenting out the import of imp
works as find_module() should be removed in python 3.12 under Ubuntu
24.04. There doesn't appear to be any fixes yet upstream in Debian Sid
which uses the same 22_fix_pymol_import.patch. Debian doesn't have a bug
report yet against python3-pymol which isn't surprising as their python3
is still at 3.11.8 in Sid.
Upstream python claims the workaround is to replace find_module with
find_spec() but I can't find a clear concise example of that coding.
Here is the relavent section of the documentation.
5.3.4. The meta path
When the named module is not found in sys.modules, Python next searches
sys.meta_path, which contains a list of meta path finder objects. These finders
are queried in order to see if they know how to handle the named module. Meta
path finders must implement a method called find_spec() which takes three
arguments: a name, an import path, and (optionally) a target module. The meta
path finder can use any strategy it wants to determine whether it can handle
the named module or not.
If the meta path finder knows how to handle the named module, it returns
a spec object. If it cannot handle the named module, it returns None. If
sys.meta_path processing reaches the end of its list without returning a
spec, then a ModuleNotFoundError is raised. Any other exceptions raised
are simply propagated up, aborting the import process.
The find_spec() method of meta path finders is called with two or three
arguments. The first is the fully qualified name of the module being
imported, for example foo.bar.baz. The second argument is the path
entries to use for the module search. For top-level modules, the second
argument is None, but for submodules or subpackages, the second argument
is the value of the parent package’s __path__ attribute. If the
appropriate __path__ attribute cannot be accessed, a ModuleNotFoundError
is raised. The third argument is an existing module object that will be
the target of loading later. The import system passes in a target module
only during reload.
The meta path may be traversed multiple times for a single import
request. For example, assuming none of the modules involved has already
been cached, importing foo.bar.baz will first perform a top level
import, calling mpf.find_spec("foo", None, None) on each meta path
finder (mpf). After foo has been imported, foo.bar will be imported by
traversing the meta path a second time, calling mpf.find_spec("foo.bar",
foo.__path__, None). Once foo.bar has been imported, the final traversal
will call mpf.find_spec("foo.bar.baz", foo.bar.__path__, None).
Some meta path finders only support top level imports. These importers
will always return None when anything other than None is passed as the
second argument.
Python’s default sys.meta_path has three meta path finders, one that
knows how to import built-in modules, one that knows how to import
frozen modules, and one that knows how to import modules from an import
path (i.e. the path based finder).
Changed in version 3.4: The find_spec() method of meta path finders
replaced find_module(), which is now deprecated. While it will continue
to work without change, the import machinery will try it only if the
finder does not implement find_spec().
Changed in version 3.10: Use of find_module() by the import system now
raises ImportWarning.
Changed in version 3.12: find_module() has been removed. Use find_spec()
instead.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2061036
Title:
pymol 2.5.0+dfsg-1build6 fails to start on noble
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pymol/+bug/2061036/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
