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/issu
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
Changes by Steve Barnes <gadgetst...@hotmail.com>:
--
pull_requests: +3126
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31182>
___
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
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 impleme
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
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 <rep...@bugs.pyt
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 <rep...@bugs.python.org>
<http://bugs.python.o
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 "de
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
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
Changes by Steve Barnes <gadgetst...@hotmail.com>:
--
pull_requests: +1671
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30362>
___
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
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
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 <rep...@bug
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 <rep...@bugs.python.org>
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
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
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
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
20 matches
Mail list logo
