[issue37556] Launcher help does not mention configuration options
New submission from Steve Barnes : py[w] --help on Windows launchers do not currently mention the options to configure versions used - just state latest. This leads some people to struggle with things like testing beta versions, etc. as they end up defaulting to the beta which is undesirable. -- components: Demos and Tools messages: 347653 nosy: Steve Barnes priority: normal severity: normal status: open title: Launcher help does not mention configuration options type: enhancement versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37556] Launcher help does not mention configuration options
Change by Steve Barnes : -- keywords: +patch pull_requests: +14500 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14701 ___ Python tracker <https://bugs.python.org/issue37556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30362] Launcher add list and list with paths options
Steve Barnes added the comment: If this option is added into the py launcher it will make it usable for a multipy script/utility that would call py -0 to get a list of installed pythons and then call it for each of the returned versions with the remaining parameters. I personally would find this very useful for things like: multipy -m pip install --upgrade matplotlib so as to install upgrades to all of the system pythons. -- ___ Python tracker <http://bugs.python.org/issue30362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28972] Document all "python -m" utilities
Steve Barnes added the comment: Having done some checks for the practicality of auto documenting library items with a -m command line usage I have to say that it will not be so simple. Many of the library items that provide useful functionality, including zipfile & tarfile, are implemented as single .py files, rather than as modules so have no __main__.py to trigger the inclusion in auto-generated documentation. I also tried searching for standard library items that use `if __name__ == "__main__":` constructs but, of course, many files simply use that to expose tests rather than useful functionality - so that is out as well. I even thought of trying for a regex that would look for this followed, in the same scope by argparse but of course there is no obligation to use it. And of course main() does not HAVE to be called main so that is out. Sorry to scotch the idea Eric! -- nosy: +Steve Barnes ___ Python tracker <http://bugs.python.org/issue28972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31182] Suggested Enhancements to zipfile & tarfile command line interfaces
New submission from Steve Barnes: I would like to add to the command line of both tarfile and zipfile interface some additional options that I believe to be useful. 1. Wildcard filename matching for archiving 2. Recursive archiving (with excludes) 3. Append to archive option 4. Compression Selection 4.1 For zipfile: zip64, bizp2 & lzma (if available) 4.2 For tarfile: document that gz, xz & bz2 are there and determined by ext. -- components: Library (Lib) messages: 300156 nosy: Steve Barnes priority: normal severity: normal status: open title: Suggested Enhancements to zipfile & tarfile command line interfaces type: enhancement versions: Python 2.7, Python 3.7 ___ Python tracker <http://bugs.python.org/issue31182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31182] Suggested Enhancements to zipfile & tarfile command line interfaces
Changes by Steve Barnes : -- pull_requests: +3126 ___ Python tracker <http://bugs.python.org/issue31182> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29829] Documentation lacks clear warning of subprocess issue with pythonw
New submission from Steve Barnes: When running under pythonw, or pyinstaller with the -w flag, modules that use subprocess calls such as popen, run, etc. will crash if the default `stdout=None, stderr=None` behaviour is used rather than PIPE. This is an obscure problem which is very hard to debug yet there is no warning in the documentation on this. I would like to suggest adding a :warning:`stdout=None, stderr=None` must not be used in any of the calls in this module when running under pythonw due to the lack of sys.stdout & sys.stderr in that case. Please use `stdout=PIPE, stderr=PIPE` instead. A patch against the default branch would be: diff -r 4243df51fe43 Doc/library/subprocess.rst --- a/Doc/library/subprocess.rstFri Feb 10 14:19:36 2017 +0100 +++ b/Doc/library/subprocess.rstThu Mar 16 16:56:24 2017 + @@ -33,6 +33,13 @@ function for all use cases it can handle. For more advanced use cases, the underlying :class:`Popen` interface can be used directly. +.. warning:: Do not use default parameters on Windows with pythonw. + + As pythonw deletes `sys.stdout` & `sys.stderr` the use of the default + parameters, `stdout=None, stderr=None,`, which defaults to being + `stdout=sys.stdout, stderr=sys.stderr,` may cause unexpected crashes + it is recommended to use `stdout=PIPE, stderr=PIPE,` instead. + The :func:`run` function was added in Python 3.5; if you need to retain compatibility with older versions, see the :ref:`call-function-trio` section. -- assignee: docs@python components: Documentation messages: 289722 nosy: Steve Barnes, docs@python priority: normal severity: normal status: open title: Documentation lacks clear warning of subprocess issue with pythonw type: behavior versions: Python 2.7, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue29829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30291] Allow windows launcher to specify bit lengths with & without minor version
New submission from Steve Barnes: Currently you can use, assuming all are installed: py -2 # gets the latest python 2 with 64 bit as the default py -2.7 # gets python 2.7 with 64 bit as the default py -2.7-32 # gets -32 bit python 2.7 py -3 # gets the latest python 3 with 64 bit as the default py -3.5 # gets python 3.5 with 64 bit as the default py -3.5-32 # gets -32 bit python 3.5 But you cannot use: py -2-32 # Usage Error but would be handy for the latest 32 bit python 2 py -3-32 # Usage Error but would be handy for the latest 32 bit python 3 Note that you also cannot use: py -3.5-64 # Unknown option: -3 would be handy for testing with I need 64 bit python 3.5 with an error if it doesn't exist currently -3.5 defaults to 3.5 64 bit if available 32 bit otherwise. For testing packages and programs it would be very useful to be able to specify any of: - Latest available 32 bit python 2 or 3 - 64 bit python 3 fail if unavailable. -- messages: 293153 nosy: Steve Barnes priority: normal severity: normal status: open title: Allow windows launcher to specify bit lengths with & without minor version type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue30291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30291] Allow windows launcher to specify bit lengths with & without minor version
Steve Barnes added the comment: Also noted when looking at the code that the validate function, (validate_version), has a couple of issues: - It will allow python major versions 0-9 (at the moment only 2 or 3 are valid). - It will not allow minor versions with more than one digit so if/when python 3.10 comes out it will stop working, (if there is a 3.10 rather than or as well as 4.0). I am not sure if these potential issues warrant a separate ticket. -- ___ Python tracker <http://bugs.python.org/issue30291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30291] Allow windows launcher to specify bit lengths with & without minor version
Steve Barnes added the comment: I believe that I have a fix in pull request #1488 for the following points, and have manually tested for them: - py Still defaults to highest py3 with 64 bits as the default - py -2/3.n-32 Still works or reports not present as appropriate - py -2/3.n-64 Works or reports not present as appropriate - py -2/3 Still defaults to highest then 64 bit if present - py -2/3-32/64 Gives highest python 2/3 or reports not present - py -2/3.nn Should now work if/when there is such a version present, (any number of digits as far as the validation goes), or reports no such python. - py -4, etc., Ditto - py n.m-anything other than 32 or 64 - no change of behaviour. CLA - Signed and submitted but not a working day yet. All automatic checks passed. Will add another push to update to the help message. -- ___ Python tracker <http://bugs.python.org/issue30291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30291] Allow windows launcher to specify bit lengths with & without minor version
Steve Barnes added the comment: CLA Now showing on profile. Minor change to help message, (Defaults to matching 64 bit installation), pushed to hopefully auto-update the CLA flag. -- ___ Python tracker <http://bugs.python.org/issue30291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30291] Allow windows launcher to specify bit lengths with & without minor version
Steve Barnes added the comment: Closing as committed in https://github.com/python/cpython/commit/870f6a11dd3b2d5455f7057ce0d9c2cd31acc2f2 -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue30291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28686] py.exe ignored PATH when using python3 shebang
Steve Barnes added the comment: If the user is operating in a virtual environment they are ring fenced and, presumably, don't wish any other versions of python to be used, (regardless of the SheBang in the files). Since we don't AFAIK have any possibility of mixed virtual environments ignoring SheBangs should meet the basic requirements of operating inside of a venv. How about a simple, but brutal approach, of if VIRTUAL_ENV is set in the current environment then always use the virtual environment python and launch with the -x option (ignore first line). This is the equivalent of using a version specifier as well as having a SheBang. This way the wrong python for the script might be executed but that is the responsibility of the person who set up the venv. -- nosy: +Steve Barnes ___ Python tracker <http://bugs.python.org/issue28686> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30362] Launcher add list and list with paths options
New submission from Steve Barnes: Currently the launcher will give an error message if a matching python is not found when using the -x.y-bits notation on the command line however the user has to know which python(s) they have available. When some pythons have been installed all user and some specific user only the individual user may well not know which pythons they have available. I would like to suggest adding to the command line -l and -L options for list and Long list options. Each option would populate the installed_pythons list and then -l print the list of usable -x.y-bits options currently available. -L print the list with the paths of the executable files. In either case the launcher should terminate after printing the list. This would be useful for deciding which python(s) to test with and for producing a list to be able to deploy critical updates to all installed pythons. -- components: Windows messages: 293642 nosy: Steve Barnes, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Launcher add list and list with paths options type: enhancement versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue30362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30362] Launcher add list and list with paths options
Changes by Steve Barnes : -- pull_requests: +1671 ___ Python tracker <http://bugs.python.org/issue30362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30362] Launcher add list and list with paths options
Steve Barnes added the comment: @steve.dower I did check and none of the currently supported pythons us -l or -L and have implemented it with -list and -long-list but I do appreciate your point that someone might come up with a use for all of these flags in a future version of python. How about dropping the short flags, (-l & -L), and making the long flags more launcher specific, i.e. --launcher-list and --launcher-list-paths spring to mind. I really do think that this change would be really useful, e.g. in the short form to generate a list of installed targets that might all need a specific library updated or to create one venv for each installed target, the long version has already helped me out spotting where a python that I was not expecting had been added to the registry. I'll also take a look over on pep514tools to see if there is anything I can do to help there. -- ___ Python tracker <http://bugs.python.org/issue30362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30362] Launcher add list and list with paths options
Steve Barnes added the comment: @terry.reedy - Very good points and I like the shortness of -0 note that there is already an accepted change to allow -x.y-64 to specifically require the 64 bit versions so we don't need the complex logic to distinguish cases where -x.y will run 32 bit because there is no 64 bit verses -x.y will run 64 bit and -x.y-32 will run 32 bit so I haven't implemented that complex logic. I have put a tab between the run flag and the path as I find that is easier to detect than some number of spaces. Found that I needed to move the test for -0 nearer the top as 0 is a potentially valid version specifier, (isdigit). Also modified the "not found" message to mention -0 as an option for discovery. -- ___ Python tracker <http://bugs.python.org/issue30362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30362] Launcher add list and list with paths options
Steve Barnes added the comment: Latest push still has -0 and -0p options for explicit discovery but also defaults to displaying the list if the requested version is not found. (As well as the default python being marked with a trailing * - I have also removed the less than helpful "default python not found when no pythons were found, (very much a corner case). I feel that the help text is a little on the long side to include the list as well in response to --help so only added it to match not found use case. I also feel quite strongly that the option for displaying the discovered paths saves a step or two in locating problem installations. -- ___ Python tracker <http://bugs.python.org/issue30362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30362] Launcher add list and list with paths options
Steve Barnes added the comment: --list and --list-paths added back in following review by paul.moore. The short options -0 & -0p left in as short forms. -- ___ Python tracker <http://bugs.python.org/issue30362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30362] Launcher add list and list with paths options
Steve Barnes added the comment: Note that the -0, --list, -0p & --list-path options will only be invoked if they are the only argument to py.exe this mirrors the original implementation of --help. -- ___ Python tracker <http://bugs.python.org/issue30362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
