[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`
New submission from Victor Varvariuc:
https://mail.python.org/pipermail/python-ideas/2017-April/045405.html
Hi there.
I asked a question
<http://stackoverflow.com/questions/41845671/import-as-in-python-3> on
Stackoverflow:
> (Pdb) import brain.utils.mail
> (Pdb) import brain.utils.mail as mail_utils
> *** AttributeError: module 'brain.utils' has no attribute 'mail'
>
> I always thought that import a.b.c as m is roughly equivalent to m =
> sys.modules['a.b.c']. Why AttributeError? Python 3.6
I was pointed out <http://stackoverflow.com/a/24968941/248296> that this is a
somewhat weird behavior of Python:
> The statement is not quite true, as evidenced by the corner case you met,
> namely if the required modules already exist in sys.modules but are yet
> uninitialized. The import ... as requires that the module foo.bar is injected
> in foo namespace as the attribute bar, in addition to being in sys.modules,
> whereas the from ... import ... as looks for foo.bar in sys.modules.
Why would `import a.b.c` work when `a.b.c` is not yet fully imported, but
`import a.b.c as my_c` would not? I though it would be vice versa.
Using `import a.b.c as my_c` allows avoiding a number of circular import
issues. Right now I have to use `from a.b import c as my_c` as a workaround,
but this doesn't look right.
The enhancement is to treat `import x.y.z as m` as `m =
importlib.import_module('x.y.z')`. I don't see how this will break anything.
--
components: Interpreter Core
messages: 291376
nosy: Victor.Varvariuc
priority: normal
severity: normal
status: open
title: Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`
type: enhancement
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue30024>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`
Victor Varvariuc added the comment: # mytest/mod2.py: import sys import mytest.mod1 assert 'mytest.mod1' in sys.modules import mytest.mod1 as mod # this fails, though the prev. lines work perfectly -- Added file: http://bugs.python.org/file46794/test.zip ___ Python tracker <http://bugs.python.org/issue30024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`
Victor Varvariuc added the comment: > I'm inclined not to attempt to fix this. The reason that we don't pull 'a.b' > out of sys.modules at this point is that if later in the execution of a/b.py > we get an exception, the import will be cancelled, and sys.modules['a.b'] > will be *deleted*, and then the variable 'c' would have a reference to a > half-loaded module. I think this is solvable -- track and delete the references too. It's your decision in the end, but I think it's not good to make the language inconsistent because of technical limitations -- the interface should be the primary source for decisions. -- ___ Python tracker <http://bugs.python.org/issue30024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`
Victor Varvariuc added the comment: > it is possible for module a to override its attribute b without updating > sys.modules This sounds like a really strange application. Even if someone overrides the attribute, when you do in other place `import a.b.c as m` you expect `a.b.c` to be path to a module, otherwise it would be hard to debug. The docs https://docs.python.org/3/reference/simple_stmts.html#import say `import_stmt ::= "import" module ["as" name]` meaning everywhere that `module` is a path to a module. https://docs.python.org/3/reference/import.html#searching > To begin the search, Python needs the fully qualified name of the module (or > package, but for the purposes of this discussion, the difference is > immaterial) being imported. This name may come from various arguments to the > import statement, or from the parameters to the importlib.import_module() or > __import__() functions. So if you treat `import a.b.c as m` as `import a; m = a.b.c` -- it go go in some cases against the docs. -- ___ Python tracker <http://bugs.python.org/issue30024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30024] Treat `import a.b.c as m` as `m = sys.modules['a.b.c']`
Victor Varvariuc added the comment: How can I facilitate/contribute to get the changes suggested by Serhiy into Python? -- ___ Python tracker <http://bugs.python.org/issue30024> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14119] Ability to adjust queue size in Executors
Victor Varvariuc added the comment: Maybe I should have created another issue for this, but without this issue being solved, the new issue will not help much. Here it is: http://hg.python.org/cpython/file/37caaf21f827/Lib/concurrent/futures/thread.py#l63 After running an work item `work_queue.task_done()` is not called. So it's difficult to know if worker threads have any more work to do. http://stackoverflow.com/questions/20965754/determine-if-worker-threads-are-doing-any-work?noredirect=1#comment31495804_20965754 -- nosy: +Victor.Varvariuc ___ Python tracker <http://bugs.python.org/issue14119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14119] Ability to adjust queue size in Executors
Victor Varvariuc added the comment:
Hi Brian,
In one my projects I had to monkey-patch module `concurrent.futures.thread:60`(
http://hg.python.org/cpython/file/37caaf21f827/Lib/concurrent/futures/thread.py#l60)
with:
def _worker(executor_reference, work_queue):
try:
while True:
work_item = work_queue.get(block=True)
if work_item is not None:
work_item.run()
work_queue.task_done() # <-- added this line
continue
executor = executor_reference()
# Exit if:
# - The interpreter is shutting down OR
# - The executor that owns the worker has been collected OR
# - The executor that owns the worker has been shutdown.
if futures_thread._shutdown or executor is None or
executor._shutdown:
# Notice other workers
work_queue.put(None)
return
del executor
except BaseException:
futures_thread._base.LOGGER.critical('Exception in worker',
exc_info=True)
This helps me to control the state of the work queue -- I can see if there are
any work items still being processed:
if executor._work_queue.unfinished_tasks:
# executor is still producing something
...
--
___
Python tracker
<http://bugs.python.org/issue14119>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14119] Ability to adjust queue size in Executors
Victor Varvariuc added the comment: Hi! Looks like your pseudocode will work as a workaround instead of monkey-patching! Still the my suggestion to add the line to code stays. self._count should be always equal to the length of self._work_queue? If yes, why duplication. If no - which one to use, why duplication? Also there is an additional lock. http://docs.python.org/3.3/library/queue.html#queue.Queue.task_done - there is a special method, why not using it? Looks like you think that `work_queue.task_done()` should not be added. I don't understand why, but you decide what's better for Python. Thank you for your time! Victor -- ___ Python tracker <http://bugs.python.org/issue14119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5845] rlcompleter should be enabled automatically
Victor Varvariuc added the comment: Here is the new issue (putting the link here for reference): http://bugs.python.org/issue22086 -- nosy: +Victor.Varvariuc ___ Python tracker <http://bugs.python.org/issue5845> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
