-
-
Notifications
You must be signed in to change notification settings - Fork 31.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Silent mode for compileall #65537
Comments
The compileall module's command line interface has a -q (quiet) flag which suppresses most of the output, but it still prints error messages. I'd like an entirely silent mode with no output. My use case is byte-compiling Python files as part of a graphical installer. I do this by running: py -${PY_QUALIFIER} -m compileall -q "$INSTDIR\pkgs" I'd like to be able to use pyw so a terminal doesn't pop up, but if I do that, it exits early. I think this is due to the issue with stdout/stderr buffers filling up on pythonw. |
This seems a reasonable request. Do you want to propose a patch? |
Patch attached. This works by making the -q flag countable, so you pass -qq to suppress all output. In the Python API, the quiet parameter has become an integer, so passing 2 is equivalent to -qq. This should be fully backwards compatible with passing True and False, which are equivalent to 1 and 0. |
Can't you just re-direct stdout or stderr? I'm sure that works even on Windows. E.g. py -${PY_QUALIFIER} -m compileall -q "$INSTDIR\pkgs" 2> null Is there a reason you cannot do this? I think that adding functionality to compileall to duplicate what your OS already provides should be a last resort. I also don't understand what you mean by "it exits early". What exits early? Surely python doesn't exit until compileall finishes running. If it does, that's a bug. |
Sorry, I somehow attached an old version of the patch. This one should be correct. Steven: Redirection relies on a shell - the native 'run a process' interface that the installer uses can't do that. There are ways to work around this, but I think this approach makes sense. It exits early because stdout and stderr don't go anywhere, so once either of them has filled up a fairly small buffer, attempts to write to it throw an error. I'd love to see that fixed, but it's been known about for years (see bpo-706263), and it seems unlikely to change any time soon. |
Gah, still wrong. Trying again. |
In fact, I will probably end up working around this anyway, because I'll have to support versions of Python without this fix for some time. So I don't feel strongly that it needs to go in, but I will do any revisions or changes requested if people think it would be useful. |
Patch looks to me comprehensive and backward-compatible. Thanks Thomas! |
Berker: I had some review comments pending on the docs, but reitveld isn't letting me publish them for some reason (it says the patch set doesn't exist). The comments are: the method docs should probably say " Otherwise the patch looks good to me, too. |
Here's an updated patch. Thanks David. |
New changeset 34436ae65523 by Berker Peksag in branch 'default': |
Thanks for the patch, Thomas. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: