Michael Blahay added the comment:
PR 13203 is still waiting for merge
--
___
Python tracker
<https://bugs.python.org/issue27639>
___
___
Python-bugs-list mailin
Michael Blahay added the comment:
PR 13203 is still waiting for merge
--
___
Python tracker
<https://bugs.python.org/issue27639>
___
___
Python-bugs-list mailin
Michael Blahay added the comment:
Thank you Mark. Everything for this one is complete. The issue may be closed.
--
___
Python tracker
<https://bugs.python.org/issue27
Michael Blahay added the comment:
Ryan, last chance, do you have any feedback?
--
___
Python tracker
<https://bugs.python.org/issue35495>
___
___
Python-bug
Michael Blahay added the comment:
The PEP is not the first place I go looking for information on Python topics,
just my two cents.
--
nosy: +mblahay
___
Python tracker
<https://bugs.python.org/issue36
Michael Blahay added the comment:
Also see https://bugs.python.org/issue35495
--
nosy: +mblahay
___
Python tracker
<https://bugs.python.org/issue17250>
___
___
Michael Blahay added the comment:
Need some help searching github to determine the blast radius of the proposed
changes. How does one look for instances of argparse.REMAINDER that are used
with a default value?
--
___
Python tracker
<ht
Michael Blahay added the comment:
For those that are wondering what is going on with PR 13181 and PR 13203, those
are both for back porting the change to 3.7. The auto generated PR 13181 failed
for an unknown reason and then the bot deleted the branch so the PR could not
be taken any
Michael Blahay added the comment:
Much detail has been provided regarding why the default is ignored when user
the REMAINDER option. The desire to add an exception has not. Is there anyone
that can provide guidance on whether the combination of:
1. Positional Argument
2. nargs=REMAINDER
3
Michael Blahay added the comment:
For the purpose of facilitating continuing conversation, here are two tests
that contrast the use of * versus REMAINDER
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('foo', nargs=1,default=['none'])
parser.add_argument('bar', nargs
Michael Blahay added the comment:
Here is another take on the issue, this time illustrated through the lens of
optional arguments.
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('--foo', nargs=1,default=['none'])
parser.add_argument('--baz', nargs='*', default=['nada
Michael Blahay added the comment:
With the optional arguments, the determination about whether to use the default
value is made based on whether the flag is present or not. When positional
arguments are involved, the need for the defaults seems to in part be
determined based on whether
Michael Blahay added the comment:
PR 13203 has finally made it through all checks successfully and is now
awaiting merging. Please someone pick it up and merge it. Thank you
--
___
Python tracker
<https://bugs.python.org/issue27
Michael Blahay added the comment:
Ryan, What say you? Will you be satisfied with the addition of a note in the
documentation?
--
___
Python tracker
<https://bugs.python.org/issue35
Michael Blahay added the comment:
At the end of msg309603 it was stated that this issue is being changed to an
enhancement. Later on, Tim Peters changed it Type back to behavior, but didn't
provide any detail about why. Should this issue still be considered an
enhancement?
--
nosy
Change by Michael Blahay :
--
pull_requests: +13114
___
Python tracker
<https://bugs.python.org/issue27639>
___
___
Python-bugs-list mailing list
Unsubscribe:
Michael Blahay added the comment:
Okay, so the expected output after running parse.parse_args([]) is
Namespace(['nothing'])
--
___
Python tracker
<https://bugs.python.org/issue35
Michael Blahay added the comment:
Ryan, I have reviewed the documentation at
https://docs.python.org/3/library/argparse.html#nargs and must admit that there
is not a definitive answer that I can see regarding the defined behavior should
there be no command line arguments that are in fact
Michael Blahay added the comment:
Here is a test that more explicitly shows the problem.
>>> from collections import UserList
>>> UserList([0,1,2,3,4,5])[0:2].__class__
>>>
It can clearly be seen here that the return type of the slicing operator is
list w
MICHAEL BLAHAY added the comment:
I will work on this
--
nosy: +MICHAEL BLAHAY
___
Python tracker
<https://bugs.python.org/issue11698>
___
___
Python-bugs-list m
MICHAEL BLAHAY added the comment:
I will pick this on up
--
nosy: +MICHAEL BLAHAY
___
Python tracker
<https://bugs.python.org/issue36582>
___
___
Python-bug
MICHAEL BLAHAY added the comment:
I have been advised to avoid enhancements like this one, so I am setting this
back down. Also, this should be relabeled as easy(c).
--
___
Python tracker
<https://bugs.python.org/issue11
MICHAEL BLAHAY added the comment:
My mistake, dfortunov is already working on this one.
--
___
Python tracker
<https://bugs.python.org/issue36582>
___
___
Pytho
Michael Blahay added the comment:
It is also worth noting that the definition of UserList moved from
Lib/UserList.py in 2.7 to Lib/collections/__init__.py in 3.x
--
___
Python tracker
<https://bugs.python.org/issue27
Michael Blahay added the comment:
The root cause of this issue seems to be the failure to implement type usage in
__getitem__ when the deprecated __getslice__ was removed. This is why slicing
worked correctly in 2.7, but not the 3.x versions.
In 3.8, the __getitem__ method is used to create
Michael Blahay added the comment:
Results from a quick unit test on the proposed changes were positive:
>>> from collections import UserList
>>> UserList([0,1,2,3,4,5])[0:2].__class__
If you compare this result with the one a couple comments above, you can see
that the r
Michael Blahay added the comment:
Let it be known that the author of PR 4981 is known as vaultah. He/she
personally closed the pull request this morning stating a lack of need to be
recognized for the work. Per his/her instructions I am reviewing the changes
and incorporating in our
Michael Blahay added the comment:
Thank you for bringing up that PR. My team will review and try to find out why
it was closed without a merge.
--
___
Python tracker
<https://bugs.python.org/issue27
Michael Blahay added the comment:
Please note that I am working with Erick Cervantes at PyCon2019 on this issue.
--
___
Python tracker
<https://bugs.python.org/issue27
Michael Blahay added the comment:
Ryan, what are the exact steps to reproduce the problem? This is what I get
when I run the code you included:
>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('things', nargs=argparse.R
MICHAEL BLAHAY added the comment:
I would like to drive this to conclusion since it appears this issue has not
had any real activity in a while. First thing that needs to be determined is
whether this enhancement is still desirable. Who can answer this?
--
nosy: +MICHAEL BLAHAY
MICHAEL BLAHAY added the comment:
Ah ha, so there is. I'm glad this one will get closed out. Sorry for noob
mistake.
--
___
Python tracker
<https://bugs.python.org/issue27
Michael Blahay added the comment:
PR 13150, the recreation of PR 4981, was noticed just after I created PR 13169.
It was decided to continue forward with PR 13169 since PR 13150 contained
changes that were out of scope for BPO-27639 for which it was suspected might
have been the cause
Michael Blahay added the comment:
Ryan, I like option A as well, but it is a breaking change. Unlike in a
compiled language where we could output a warning, making the proposed change
could bring some software to a grinding halt. For now I'm going to make the
documentation change
34 matches
Mail list logo
