[issue26271] freeze.py makefile uses the wrong flags variables
New submission from Daniel Shaulov: Tools/Freeze/makemakefile.py uses CFLAGS, LDFLAGS and CPPFLAGS instead of the PY_ prefixed versions. This makes flags passed to ./configure ineffective. The patch makes the trivial fix of adding PY_ when needed. -- components: Build files: pyflags.patch keywords: patch messages: 259444 nosy: Daniel Shaulov priority: normal severity: normal status: open title: freeze.py makefile uses the wrong flags variables type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41785/pyflags.patch ___ Python tracker <http://bugs.python.org/issue26271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26271] freeze.py makefile uses the wrong flags variables
Daniel Shaulov added the comment: Pinging after a month without review (as the devguide suggests). -- ___ Python tracker <http://bugs.python.org/issue26271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26534] subprocess.check_output with shell=True ignores the timeout
New submission from Daniel Shaulov:
Basically -
subprocess.check_output("ping localhost", shell=True, timeout=5)
Will hang forever.
What happens is that subprocess.run times out on communicate, sends SIGKILL *to
the shell* and then calls communicate again without the timeout. But nothing
actually closes the "ping" command so the second communicate will never exit.
Even if we put a timeout on the second communicate, it won't be good enough
because that "ping" will still be "leaked".
This SO question is about the fact that kill doesn't work when shell=True, and
might be relevant for this issue:
http://stackoverflow.com/questions/4789837/how-to-terminate-a-python-subprocess-launched-with-shell-true
As a possible fix I propose doing the following:
1. Add killpg to the Popen class.
2. Add an argument to run - "kill_group" that makes run use killpg instead of
kill
3. Users can all:
subprocess.check_output("ping localhost", shell=True, start_new_session=True,
kill_group=True, timeout=5)
And have it work fine. This is the best I could come up with, without breaking
any existing behavior.
Other options to consider:
1. Not have kill_group argument and to implicitly kill by group when
start_new_session is True (but this is not really backwards compatible).
2. Having kill_group as an argument for Popen and not run, and when kill is
called, it will call killpg if the option was specified.
A patch is attached with my proposed solution.
--
components: Library (Lib)
files: killpg.patch
keywords: patch
messages: 261533
nosy: Daniel Shaulov, astrand
priority: normal
severity: normal
status: open
title: subprocess.check_output with shell=True ignores the timeout
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42122/killpg.patch
___
Python tracker
<http://bugs.python.org/issue26534>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26539] frozen executables should have an empty path
New submission from Daniel Shaulov: A frozen python executable should have an empty path, so it doesn't accidentally run something it was not supposed to. The attached file achieves that by setting Py_NoSiteFlag and Py_IsolatedFlag in Python/frozenmain.c It also checks for Py_FrozenFlag in Python/sysmodule.c in makepathobject and just returns an empty list if it is set. I originally tried doing it without changing sysmodule, by calling Py_SetPath as suggested in the comment in getpath.c, but calling Py_SetPath(L"") will leave me with a path that cointains a single empty string. There is no way to set an empty path with Py_SetPath. Other options include allowing Py_SetPath to accept NULL and making sure that NULL results in an empty list, or changing the behavior of makepathobject so an empty string will result in an empty list instead of a list with an empty string. -- components: Demos and Tools files: freeze_path.patch keywords: patch messages: 261566 nosy: Daniel Shaulov, twouters priority: normal severity: normal status: open title: frozen executables should have an empty path type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file42133/freeze_path.patch ___ Python tracker <http://bugs.python.org/issue26539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26646] Allow built-in module in package
New submission from Daniel Shaulov: Hi, I was trying to build a python interpreter that has the cpp part of msgpack as a built-in module. I thought that I could just copy the msgpack folder to the Modules folder and add this 2 lines to Modules/Setup.local: msgpack._packer msgpack/_packer.cpp msgpack._unpacker msgpack/_unpacker.cpp I had a few obstacles, the attached patch fixes them all. The first - makesetup has a list of regexes to match and it has *.* after going through all known extensions to throw a "bad word" error. I removed the check. All those things will now be assumed to be a module with a package. Now the actual init function name is PyInit__packer and doesn't have msgpack in it, so I also added code in makesetup to use the full name as the name and only the module name for the PyInit function. The second is that in Lib/importlib/_bootsrap.py in BuiltinImporter.find_spec there is a specific case to ignore modules that are part of a package. Is there a reason to forbid it? I removed that check. There were also unit tests that checked this behavior which I deleted. I added tests that check module in package instead of them. Changing _bootsrap.py also changes Python/importlib.h (it is the frozen importlib), I added a separate patch with that change, to not clutter the main patch. The third - the __name__ didn't have the package prefix. Digging around I found a comment in PyModule_Create2 that says that the shared library loader stores the full name _Py_PackageContext before loading the module, so I did the same in _imp_create_builtin that is done in _PyImport_LoadDynamicModuleWithSpec to set _Py_PackageContext and the __name__ was fixed too. (If anyone tries to do this with msgpack and wants to see that it works - you also need to copy the msgpack directory to the Lib directory, and in __init__.py, where it catches the import error and goes to the fallback, just reraise the exception instead of letting it go to the fallback) Do note that this does not allow for built-in packages, only build-it module in package. If we want to allow built-in packages, we will need to decide on some syntax to distinguish it in the Setup files and some way to distinguish them in PyImport_Inittab (for example - an asterix before the name of the package?) Thanks, Daniel. -- components: Build, Interpreter Core files: builtin_package.patch keywords: patch messages: 262495 nosy: Daniel Shaulov, brett.cannon, eric.snow, ncoghlan priority: normal severity: normal status: open title: Allow built-in module in package type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file42297/builtin_package.patch ___ Python tracker <http://bugs.python.org/issue26646> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26646] Allow built-in module in package
Changes by Daniel Shaulov : Added file: http://bugs.python.org/file42298/importlib_h.patch ___ Python tracker <http://bugs.python.org/issue26646> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26646] Allow built-in module in package
Daniel Shaulov added the comment: Hi Brett, I don't think that the patch from that issue is relevant anymore. I did take the test case that was proposed in that issue and I am attaching a fixed version here. I did realize from the discussion that my patch probably doesn't work on Windows (I think the change itself is fine - It's just won't have the test module), I will try to get a working Windows environment and make the appropriate changes tomorrow. Also, the other issue was also asking for built-in packages and not just built-in submodules. I already have a note about that in my original message. Can we move forward as-is or do you want me to add support for built-in packages as well? -- Added file: http://bugs.python.org/file42350/test_builtin_submodule.py ___ Python tracker <http://bugs.python.org/issue26646> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
