[issue13314] ImportError ImportError: Import by filename, should be deferred until sys.meta_path hooks are processed
New submission from Rob Bairos :
When adding hooks to sys.meta_path, to correctly deal with arbitrarily named
non-disk module definitions, module names with slashes should still be
processed.
As it stands when executing statements such as:
import my_module_123#/123
or
even
__import__('my_module_123#/123')
the following exception is raised:
ImportError: Import by filename is not supported.
This stops sys.meta_path from handling arbitrarily named modules.
Shouldn't the ImportError be raised *after* the meta_path processing, at which
point, its safe to assume the name is a disk name, in which case slashes are
relevant?
--
components: Interpreter Core
messages: 146799
nosy: Rob.Bairos
priority: normal
severity: normal
status: open
title: ImportError ImportError: Import by filename, should be deferred until
sys.meta_path hooks are processed
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue13314>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13314] ImportError ImportError: Import by filename, should be deferred until sys.meta_path hooks are processed
Changes by Rob Bairos : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue13314> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13314] ImportError ImportError: Import by filename, should be deferred until sys.meta_path hooks are processed
Rob Bairos added the comment: Why is a module name syntactically improper simply because it contains a slash? That seems an arbitrary definition, that serves no purpose, except to discourage accidentally specifying a filename. Module with unusual characters all reach the meta_path stage, eg: my,mo*d1?2my##m;o#d13 But as soon as a slash is introduced, a warning that filenames not being supported is thrown. 1) If the issue is that its not syntactically correct, it should state so. 2) If the issue is that its not syntactically correct, the syntax of a module name should be documented to include *,?# or throw the same exception. 3) Whats the purpose of the 'Import my filename' exception anyhow? Will it not fail soon thereafter at any rate? This behaviour is definitely inconsistent and arbitrary. -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue13314> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13314] ImportError ImportError: Import by filename, should be deferred until sys.meta_path hooks are processed
Rob Bairos added the comment: Yah, thinking about this further, the real error is that sys.meta_path allows processing of names with #,?* etc. I can see why this would cause problems, as python names must only be _ and alphanumeric characters. I'll re-implement this. Thanks. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue13314> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18812] PyImport_Import redundant calls to find module
New submission from Rob Bairos: Why does PyImport_Import (import.c) call __import__ then immediately discard the result, and then look for the module again in the module dictionary? It will return the same value in both cases no? Ive included the relevant portion of the code below. Its breaking an embedded application we've built where a hierarchy of modules are maintained outside the sys.modules dictionary. /* Call the __import__ function with the proper argument list Always use absolute import here. Calling for side-effect of import. */ r = PyObject_CallFunction(import, "i", module_name, globals, globals, silly_list, 0, NULL); if (r == NULL) goto err; //-- WHY IS THIS SECTION NEEDED? Py_DECREF(r); modules = PyImport_GetModuleDict(); r = PyDict_GetItem(modules, module_name); if (r != NULL) //--- Py_INCREF(r); -- components: Interpreter Core messages: 195915 nosy: Rob.Bairos priority: normal severity: normal status: open title: PyImport_Import redundant calls to find module versions: Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue18812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18812] PyImport_Import redundant calls to find module
Changes by Rob Bairos : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue18812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18812] PyImport_Import redundant calls to find module
Rob Bairos added the comment: However, if it fails __import()__ it doesn't get to the sys.modules[] call anyways. The only case affected by this are: PASS the __import()__ call, then FAIL the sys.modules[] lookup afterwards. Why will that effect anything currently out there? As it stands now, it suppresses development of some types of dynamic hierarchies of modules such as we've implemented, that don't register themselves in sys.modules[] -- ___ Python tracker <http://bugs.python.org/issue18812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18812] PyImport_Import redundant calls to find module
Rob Bairos added the comment: Okay, thanks for looking into it. Cheers -- ___ Python tracker <http://bugs.python.org/issue18812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27383] executuable in distutils triggering microsoft anti virus
New submission from Rob Bairos: python 3.5: wininst-14.0.exe Is triggering Microsoft Security Essentials virus detection: Recommended action: Remove this software immediately. Items: file:D:\PythonBuilds\202ee57ca3\py\Lib\distutils\command\wininst-14.0.exe I've tried on two separate machines so far, with same quarantine. Microsoft Security Essentials (running on Windows 7) Antimalware Client Version: 4.9.218.0 Engine Version: 1.1.12805.0 Antivirus definition: 1.223.2544.0 Antispyware definition: 1.223.2544.0 Network Inspection System Engine Version: 2.1.12706.0 Network Inspection System Definition Version: 116.10.0.0 -- components: Distutils messages: 269186 nosy: Rob Bairos, dstufft, eric.araujo priority: normal severity: normal status: open title: executuable in distutils triggering microsoft anti virus type: security versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue27383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27383] executuable in distutils triggering microsoft anti virus
Rob Bairos added the comment: thanks for the quick action! -- ___ Python tracker <http://bugs.python.org/issue27383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27383] executuable in distutils triggering microsoft anti virus
Rob Bairos added the comment: Great. Thanks for the update On Tue, Jun 28, 2016 at 2:37 PM, Steve Dower wrote: > > Steve Dower added the comment: > > FYI the definitions have been updated and I'm no longer seeing the false > positive. > > Definition version: 1.223.2858.0 > > -- > > ___ > Python tracker > <http://bugs.python.org/issue27383> > ___ > -- ___ Python tracker <http://bugs.python.org/issue27383> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
