[issue38438] argparse "usage" overly-complex with nargs="*"

2019-10-10 Thread Bob Alexander


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



[issue24505] shutil.which wrong result on Windows

2016-04-04 Thread Bob Alexander

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 <rep...@bugs.python.org>
<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

2016-04-04 Thread Bob Alexander

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 <rep...@bugs.python.org>
<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

2015-06-27 Thread Bob Alexander

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 rep...@bugs.python.org
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 rep...@bugs.python.org
 http://bugs.python.org/issue24505
 ___


--

___
Python tracker rep...@bugs.python.org
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

2015-06-24 Thread Bob Alexander

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 rep...@bugs.python.org
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 (mingling --option and optional positional argument)

2015-05-21 Thread Bob Alexander

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 rep...@bugs.python.org
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 stdin, line 1, in module
   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 rep...@bugs.python.org
 http://bugs.python.org/issue24223
 ___


--

___
Python tracker rep...@bugs.python.org
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 bug

2015-05-17 Thread Bob Alexander

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 rep...@bugs.python.org
http://bugs.python.org/issue24223
___
___
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

2013-03-30 Thread Bob Alexander

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 rep...@bugs.python.org
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

2013-03-27 Thread Bob Alexander

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 rep...@bugs.python.org
 http://bugs.python.org/issue17551
 ___


--

___
Python tracker rep...@bugs.python.org
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

2013-03-26 Thread Bob Alexander

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 rep...@bugs.python.org
http://bugs.python.org/issue17551
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com