[issue9072] Unloading modules - memleaks?
New submission from Slava : I don't know whether this is a bug, but my exhaustive search led me to "Python can't really unload modules" from every direction, which I find hard to believe, I don't know where else to go with this. The problem: import gc, sys print len(gc.get_objects()) # 4073 # starting with 4073 objects in memory import httplib del sys.modules["httplib"] del httplib # httplib should be unloaded # and garbage collected as it is unreachable gc.collect() print len(gc.get_objects()) # 6745 # 6745 objects in memory (2000+ stray objects) This applies to almost any module. Is this a bug or somehow correctable? -- components: None messages: 108545 nosy: yappie priority: normal severity: normal status: open title: Unloading modules - memleaks? type: resource usage versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue9072> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9072] Unloading modules - memleaks?
Slava added the comment: Thank you for taking time to answer my question about unloading modules. I really appreciate it! Slava On Fri, Jun 25, 2010 at 2:43 AM, Martin v. Löwis wrote: > > Martin v. Löwis added the comment: > > This is not a bug. You didn't *nearly* reset Python to the state in which > it was before the import: the modules that got imported recursively still > hang in sys.modules. > > Please accept that Python indeed does not support unloading modules for > severe, fundamental, insurmountable, technical problems, in 2.x. > > In 3.x, chances are slightly higher. In principle, unloading could be > supported - but no module actually adds the necessary code, and the > necessary code in the import machinery isn't implemented in 3.2 and earlier. > > Supporting unloading will be (and was) a multi-year project. Don't expect > any results in the next five years. > > -- > nosy: +loewis > resolution: -> wont fix > status: open -> closed > > ___ > Python tracker > <http://bugs.python.org/issue9072> > ___ > -- Added file: http://bugs.python.org/file17764/unnamed ___ Python tracker <http://bugs.python.org/issue9072> ___Thank you for taking time to answer my question about unloading modules. I really appreciate it!SlavaOn Fri, Jun 25, 2010 at 2:43 AM, Martin v. Löwis <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Martin v. Löwis <mailto:mar...@v.loewis.de";>mar...@v.loewis.de> added the comment: This is not a bug. You didn't *nearly* reset Python to the state in which it was before the import: the modules that got imported recursively still hang in sys.modules. Please accept that Python indeed does not support unloading modules for severe, fundamental, insurmountable, technical problems, in 2.x. In 3.x, chances are slightly higher. In principle, unloading could be supported - but no module actually adds the necessary code, and the necessary code in the import machinery isn't implemented in 3.2 and earlier. Supporting unloading will be (and was) a multi-year project. Don't expect any results in the next five years. -- nosy: +loewis resolution:  -> wont fix status: open -> closed ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue9072"; target="_blank">http://bugs.python.org/issue9072> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26473] Python 3.5 not run
New submission from Slava: Python 3.5 not run on Windows Server 2003 (PE mode). Python 3.5 installer not work too. -- components: Windows files: Clipboard01.jpg messages: 261134 nosy: newillusion, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python 3.5 not run type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file42064/Clipboard01.jpg ___ Python tracker <http://bugs.python.org/issue26473> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42940] Incorrect behavior of inspect.signature(f).bind
New submission from Slava Kostrov : >>> def foo(a, /, b=1, **kwargs): pass ... >>> foo(a=1) Traceback (most recent call last): File "", line 1, in TypeError: foo() missing 1 required positional argument: 'a' >>> inspect.signature(foo).bind(a=1) Traceback (most recent call last): File "", line 1, in File "\Python\Python39\lib\inspect.py", line 3062, in bind return self._bind(args, kwargs) File "\Python\Python39\lib\inspect.py", line 2958, in _bind raise TypeError(msg) from None TypeError: 'a' parameter is positional only, but was passed as a keyword There is a different behaviour between a simple function call and inspect.signature(foo).bind - different TypeError messages. I think inspect should check for VARKEYWORDS before throwing an error and throw only if there are not. -- messages: 385143 nosy: slavkostrov priority: normal severity: normal status: open title: Incorrect behavior of inspect.signature(f).bind type: behavior versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32068] textpad from curses package isn't handling backspace key
New submission from Slava Bacherikov : textpad isn't handling backspace key on my system and seems on others too. When I press backspace key, terminal sends `ascii.DEL` (127) and it isn't handled by textpad. I've attached patch that fixes this, should I also create PR for this or patch is enough ? -- components: Library (Lib) files: textpad.patch keywords: patch messages: 306481 nosy: bacher09 priority: normal severity: normal status: open title: textpad from curses package isn't handling backspace key type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file47272/textpad.patch ___ Python tracker <https://bugs.python.org/issue32068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
