[issue38438] argparse "usage" overly-complex with nargs="*"
New submission from Bob Alexander :
This program:
import argparse
ap = argparse.ArgumentParser()
ap.add_argument("arg", nargs="*")
ap.parse_args()
Gives usage message:
usage: help_complexity.py [-h] [arg [arg ...]]
It's correct, but unnecessarily complex and challenging to the user.
If I were manually writing the usage, arg... would do, or maybe [arg ...] to be
consistent with other messages??
--
components: Library (Lib)
messages: 354402
nosy: bobjalex
priority: normal
severity: normal
status: open
title: argparse "usage" overly-complex with nargs="*"
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue38438>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17551] Windows - accessing drive with nothing mounted forces user interaction
New submission from Bob Alexander: Attempting to use os.path.exists on a Windows drive that is a mobile device mount point with nothing mounted pops up a dialog asking to insert a device. This makes it impossible to search a set of drives for a specific file without the possibility of unnecessary user interaction -- for example looking for the drive that has a specific flash drive inserted. This behavior is likely related to bug 9035 regarding "os.path.ismount" behavior on Windows. The more correct behavior (IMO) would be to quietly return exists=False for drives with nothing mounted. In fact, I tried the same operation with Java and Ruby programs, and both simply return false with no popup. -- components: Library (Lib) messages: 185281 nosy: bobjalex priority: normal severity: normal status: open title: Windows - accessing drive with nothing mounted forces user interaction type: behavior versions: Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.org/issue17551> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17551] Windows - accessing drive with nothing mounted forces user interaction
Bob Alexander added the comment: Thanks for the prompt reply! Your suggested change does change the behavior to exactly the way I think it should work by default. Tried it on both Windows 7 and Vista; no popups when accessing a "mobile mount" drive with nothing in it, just quietly reports False. I vote for making this the normal behavior of these "file exists" sort of operations. Hmm, I notice that msvcrt.SetErrorMode is not discussed in the current Python 3 Standard Library docs... :-) Bob On Wed, Mar 27, 2013 at 6:40 AM, Amaury Forgeot d'Arc < rep...@bugs.python.org> wrote: > > Amaury Forgeot d'Arc added the comment: > > Does it change something if you insert in your script (in 3.3): > import msvcrt > msvcrt.SetErrorMode(msvcrt.SEM_FAILCRITICALERRORS) > > -- > nosy: +amaury.forgeotdarc > > ___ > Python tracker > <http://bugs.python.org/issue17551> > ___ > -- ___ Python tracker <http://bugs.python.org/issue17551> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17551] Windows - accessing drive with nothing mounted forces user interaction
Bob Alexander added the comment: Thanks Terry. I agree that it's a bug. And, in the future I'll be more careful about trimming the "history" from my messages :-) Bob -- ___ Python tracker <http://bugs.python.org/issue17551> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24505] shutil.which wrong result on Windows
New submission from Bob Alexander:
Python session with 3.5b2
Showing existing error:
>>> from shutil import which
Works OK
>>> which("python")
'C:\\Python27\\python.EXE'
Also works OK
>>> which('C:\\Python27\\python.EXE')
'C:\\Python27\\python.EXE'
Fails
>>> which('C:\\Python27\\python')
>>>
Showing better results with my fix (attached):
>>> from which2 import which
>>> which("python")
'C:\\Python27\\python.exe'
>>> which('C:\\Python27\\python.exe')
'C:\\Python27\\python.exe'
>>> which('C:\\Python27\\python')
'C:\\Python27\\python.exe'
Problem is with the short-circuiting code near the beginning of the function.
It fails to check the extensions for Windows when short-circuited.
My fix has a few other improvements -- efficiency and nicer output without
those ugly upper-case extensions.
--
components: Library (Lib)
files: which2.py
messages: 245780
nosy: bobjalex
priority: normal
severity: normal
status: open
title: shutil.which wrong result on Windows
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file39805/which2.py
___
Python tracker
<http://bugs.python.org/issue24505>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24505] shutil.which wrong result on Windows
Bob Alexander added the comment: Hi R. David -- My report is just to notify y'all of a bug that I noticed. The bug is causing me no problem, and it's your option as to whether to fix it or not. I offered a fix, but I haven't the time to perform diffs, etc. You could make that diff yourself, since I sent my modified "which" function. Just replace the existing "which" function in the version of shutil you would like to fix, and perform the diff. Bob On Wed, Jun 24, 2015 at 8:26 PM, R. David Murray wrote: > > R. David Murray added the comment: > > Could you please submit your proposal as a patch? (A diff -u against the > existing version). > > -- > nosy: +r.david.murray > > ___ > Python tracker > <http://bugs.python.org/issue24505> > ___ > -- ___ Python tracker <http://bugs.python.org/issue24505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24505] shutil.which wrong result on Windows
Bob Alexander added the comment: Since there seems to be ongoing work on the "which" function, here are a few more thoughts on this function's future: - The existing version does not prepend the current directory to the path if it is already in the path. If the current directory is in the path but is not the first element, it will not be the first directory searched. It seems that the desired behavior is to search the current directory first, so the current directory should *always* be prepended. The existing "which" function already has an optimization to only search each directory once, so it's not a problem if the current directory is unconditionally prepended and may end up in there twice. This change would actually be a "correction", since the doc says the current directory is prepended - The function should always return an absolute path, which is the behavior of the Unix(1) "which" command and, I think, is the typical expected behavior of a "which"-type request. The existing implementation returns a relative path in certain cases, such as if the file is found via a relative directory reference in the path. This change is not inconsistent with the doc, since the doc does not address it. - It would be nice if the extension added when the given command has no extension were lower case, instead of the upper case extension retrieved from the PATHEXT environment variable. Several other "which" implementations work that way (e.g. see Go's os/exec.LookPath function), producing a more aesthetically pleasing name, as well as being more consistent with naming practices of the last 20+ years. The shocking-looking upper case sxtensions remind me of VERY OLD DOS programs :-) This presents no conflict with the doc, and does not affect "correctness" since Windows file names are case-independent. A previous commenter objected to adding lower case extensions, but consider: - The current version never returns the extension case of the actual file. It returns the extension of the command string passed to the function, if any, otherwise it adds the extension from the PATHEXT environment variable, either of which might not match the actual file. - Returning the actual extension of the found file might be nice, but would require additional I/O; added expense for little return. This is not done in the current version. - The PATHEXT variable that ships with Windows contains the allowable extensions in upper case, an old DOS artifact. Few executable files these days have uppercase extensions. Using a lower case extension when the function has to invent one is a "modernization". - It would be nice if the returned file path were normalized. Currently, sometimes an unnormalized path is returned with a leading ".\". I did write an update to "which" with the above changes, and also updated the unit tests with: - 2 new tests to catch the bug that is the subject of this issue. - some tests were updated for the small changes such as normalization and lower case added extensions. A zip file is attached with my updates. I'm not an official "contributor", but feel free incorporate the contents in any way you deem appropriate. The files are: shutil.py updated shutil module shutil.py_3_5_1 existing 3.5.1 shutil module -- basis for updates test_shutil_for_current_w_added_tests.py unit tests for existing 3.5.1 version of shutil with new tests to catch this bug test_shutil_for_new_version.py unit tests for attached updated version of shutil test_shutil_3_5_1.py existing 3.5.1 unit tests -- basis for updates Bob -- Added file: http://bugs.python.org/file42365/new_which_bug_files.zip ___ Python tracker <http://bugs.python.org/issue24505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24505] shutil.which wrong result on Windows
Bob Alexander added the comment: Oops, clarification... I just reread my kind of long previous post, and realized it wasn't very explicit that anything concerning file extensions or prepending the current directory to the PATH apply to Windows only; not Unix (of course). The "returning absolute, normalized paths" suggestions are multi-platform I only tested the modified code on Windows. -- ___ Python tracker <http://bugs.python.org/issue24505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24223] argparse parsing bug
New submission from Bob Alexander:
Here is simple example of failure to parse arguments that should parse OK. In
the following little program, the second from last line contains an aargument
sequence that parses OK, but the last line should but doesn't.
import argparse
ap = argparse.ArgumentParser()
ap.add_argument("--option", action="store_true")
ap.add_argument("arg_1")
ap.add_argument("arg_2", nargs="?")
print("test 1:", ap.parse_args(["abc", "mmm", "--option"]))
print("test 2:", ap.parse_args(["abc", "--option", "mmm"]))
--
components: Library (Lib)
messages: 243447
nosy: bobjalex
priority: normal
severity: normal
status: open
title: argparse parsing bug
type: behavior
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue24223>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24223] argparse parsing (mingling --option and optional positional argument)
Bob Alexander added the comment:
Thanks for the note, Martin. I agree that it's a duplicate. (I had done a
brief search for possible dups, but didn't find that one!)
Bob
On Sun, May 17, 2015 at 8:29 PM, Martin Panter
wrote:
>
> Martin Panter added the comment:
>
> I suggest this is a duplicate of Issue 15112. The same problem also
> happens with nargs="*", and that issue apparently has a patch to handle
> both cases.
>
> For the record, this is the resulting error, and a demo that it works if
> the option comes before the positional arguments:
>
> >>> print("test 2:", ap.parse_args(["abc", "--option", "mmm"]))
> usage: [-h] [--option] arg_1 [arg_2]
> : error: unrecognized arguments: mmm
> Traceback (most recent call last):
> File "", line 1, in
> File "/home/proj/python/cpython/Lib/argparse.py", line 1729, in
> parse_args
> self.error(msg % ' '.join(argv))
> File "/home/proj/python/cpython/Lib/argparse.py", line 2385, in error
> self.exit(2, _('%(prog)s: error: %(message)s\n') % args)
> File "/home/proj/python/cpython/Lib/argparse.py", line 2372, in exit
> _sys.exit(status)
> File "/home/pythonstartup.py", line 345, in exit
> raise SystemExit(code)
> __main__.SystemExit: 2
> >>> ap.parse_args(["--option", "abc", "mmm"])
> Namespace(arg_1='abc', arg_2='mmm', option=True)
>
> --
> nosy: +vadmium
> resolution: -> duplicate
> stage: -> resolved
> status: open -> closed
> superseder: -> argparse: nargs='*' positional argument doesn't accept any
> items if preceded by an option and another positional
> title: argparse parsing bug -> argparse parsing (mingling --option and
> optional positional argument)
>
> ___
> Python tracker
> <http://bugs.python.org/issue24223>
> ___
>
--
___
Python tracker
<http://bugs.python.org/issue24223>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
