Steven Bethard steven.beth...@gmail.com added the comment:
Actually closing this time. Duplicate of issue 9553.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9345
Steven Bethard steven.beth...@gmail.com added the comment:
Unassigning, because it's likely I won't have time to work on this for a while.
I still think it would be a nice feature. ;-)
--
assignee: bethard -
___
Python tracker rep
Steven Bethard steven.beth...@gmail.com added the comment:
You can specify either 1 or N. So for n=3, you can specify metavar=X or
metavar=(X, Y, Z) but not metavar=(X, Y). The special nargs value ?
always takes only one, while * and + always take two. (This makes sense if
you think about how
Steven Bethard steven.beth...@gmail.com added the comment:
Yep, I'm fine with you committing this (after adding the prefix=+-/ you
suggested). I don't have time right now to test the patches, but the code looks
about right, and the tests ran fine for you, so I'm fine
Steven Bethard steven.beth...@gmail.com added the comment:
Yes, this looks fine, assuming a test is also added.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9444
Steven Bethard steven.beth...@gmail.com added the comment:
The patch looks basically right. A few minor issues:
* message=None, should probably be message,, that is, message should not be
allowed to default to None - I can't see any use case for this action without a
message. I believe
Steven Bethard steven.beth...@gmail.com added the comment:
It is intentional that you have to specify both /foo and +foo if you want
them to be aliases for the same argument. A common use case for prefix_chars is
to define +x and -x options, which usually mean different things.
As far
Steven Bethard steven.beth...@gmail.com added the comment:
A doc patch would also be welcome, but I do think it's a bug that
ArgumentParser(prefix_chars='+') throws an exception, and I think Ted's patch
looks fine to me.
--
___
Python tracker rep
Steven Bethard steven.beth...@gmail.com added the comment:
The equivalent to optparse callback is basically to define __call__ in a
subclass of Action. Pretty much the same amount of work because they both have
complicated parameters.
The callable I (not fully confidently) proposed would just
Steven Bethard steven.beth...@gmail.com added the comment:
Should this print to stdout or stderr? I wonder if the API should allow either,
and instead look like:
parser.add_argument('--license', action='write', message='...', file=sys.stdout)
Where sys.stdout would be the default for the file
Steven Bethard steven.beth...@gmail.com added the comment:
It *would* be a backwards incompatible change. Currently, if I have a parser
with both a --foo and a --bar option, and my user types --foo --bar, they
get an error saying that they were missing the argument to --foo. Under your
Steven Bethard steven.beth...@gmail.com added the comment:
I still disagree. You're giving the parser ambiguous input. If a parser sees
--foo --bar, and --foo is a valid option, but --bar is not, this is a
legitimately ambiguous situation. Either the user really wanted --bar, and
the parser
New submission from Steven Bethard steven.beth...@gmail.com:
[From the old argparse tracker:
http://code.google.com/p/argparse/issues/detail?id=20]
You can't follow a nargs='+' optional argument with a positional argument:
import argparse
parser = argparse.ArgumentParser(prog='PROG
Steven Bethard steven.beth...@gmail.com added the comment:
Note that the negative number heuristic you're complaining about doesn't
actually affect your code below. The negative number heuristic is only used
when you have some options that look like negative numbers. See the docs for
more
Steven Bethard steven.beth...@gmail.com added the comment:
This is definitely a different bug from the one you just marked it as a
duplicate of.
--
resolution: duplicate -
stage: committed/rejected - needs patch
status: closed - open
superseder: argparse does not accept options taking
New submission from Steven Bethard steven.beth...@gmail.com:
[Moved from http://code.google.com/p/argparse/issues/detail?id=45]
If you try to use parse_known_args and you have a subparser, the subparser will
still complain if it sees extra arguments:
parser = argparse.ArgumentParser
New submission from Steven Bethard steven.beth...@gmail.com:
[Moved from http://code.google.com/p/argparse/issues/detail?id=53]
It's currently not possible to have subcommands formatted in groups, e.g.
instead of:
subcommands:
{a,b,c,d,e}
a a subcommand help
b b
Steven Bethard steven.beth...@gmail.com added the comment:
In argparse, -debug is a perfectly valid flag (you're not required to have
--debug, and you can even have +debug if you want and you specify it
correctly), so unless I misunderstand what the bug is, this doesn't apply to
argparse
Steven Bethard steven.beth...@gmail.com added the comment:
Not sure, but I think _print_message in argparse isn't exactly what the OP is
looking for if they really only care about errors. If you want to override how
errors are printed, then it's absolutely correct to override the error method
New submission from Steven Bethard steven.beth...@gmail.com:
[From http://code.google.com/p/argparse/issues/detail?id=61]
It should be documented clearly that only the arguments present on the parent
parser at the time ArgumentParser is called will be included in the parser.
parent
Steven Bethard steven.beth...@gmail.com added the comment:
Ah, thanks for the fix. No it doesn't need to go in 3.1 - argparse is only in
2.7 and 3.2.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9343
New submission from Steven Bethard steven.beth...@gmail.com:
[From http://code.google.com/p/argparse/issues/detail?id=63]
What steps will reproduce the problem?
1. PYTHONPATH=. python test/test_argparse.py
2. do the above in an 80x24 terminal window and it passes
3. do the same in an 80 wide
New submission from Steven Bethard steven.beth...@gmail.com:
What steps will reproduce the problem?
parser = argparse.ArgumentParser()
parser.add_argument('--foo', type=(int, float))
What is the expected output?
ValueError: (type 'int', type 'float') is not callable
What do you see instead
New submission from Steven Bethard steven.beth...@gmail.com:
What steps will reproduce the problem?
parser = argparse.ArgumentParser()
parser.add_argument('--foo', nargs=2, metavar=('X','Y','Z'))
parser.parse_args(['-h'])
The error dosn't show up until help is formatted.
Giving any
New submission from Steven Bethard steven.beth...@gmail.com:
Argparse supports silencing help for certain options using SUPPRESS.
parser = argparse.ArgumentParser()
parser.add_argument('--foo', help=argparse.SUPPRESS)
parser.print_help()
usage: [-h]
optional arguments:
-h, --help show
New submission from Steven Bethard steven.beth...@gmail.com:
[From http://code.google.com/p/argparse/issues/detail?id=71]
There is a method ArgumentParser.add_argument_group() to create and add an
argument group to the parser. I would like the ability to remove an argument
group via a method
New submission from Steven Bethard steven.beth...@gmail.com:
If you use set_defaults on a subparser, but a default exists on the top level
parser, the subparser defaults are ignored:
parser = argparse.ArgumentParser()
xparser = parser.add_subparsers().add_parser('X')
parser.set_defaults(foo
New submission from Steven Bethard steven.beth...@gmail.com:
[Moved from http://code.google.com/p/argparse/issues/detail?id=73]
What steps will reproduce the problem?
parser = ArgumentParser(prefix_chars=-+)
parser.add_argument(-a,action=store_true)
parser.add_argument(+b,action=store_true
New submission from Steven Bethard steven.beth...@gmail.com:
[Moved from http://code.google.com/p/argparse/issues/detail?id=75]
What steps will reproduce the problem?
1. import argparse
2. print dir(argparse)
3. print argparse.__all__
Compare the output for public methods and attributes from
New submission from Steven Bethard steven.beth...@gmail.com:
[Moved from http://code.google.com/p/argparse/issues/detail?id=78]
What steps will reproduce the problem?
1. Create two mutually exclusive groups: eg
agroup = subcmd_parser.add_mutually_exclusive_group()
agroup.add_argument('--a1
Steven Bethard steven.beth...@gmail.com added the comment:
Yes, please generate patches from the Python repository.
Thanks!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9026
Changes by Steven Bethard steven.beth...@gmail.com:
--
assignee: - bethard
nosy: +bethard
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9026
Steven Bethard steven.beth...@gmail.com added the comment:
Given that the one obvious way of using dict-style syntax given a Python object
is to call vars(), I thing adding a __getitem__ is probably a bad idea.
--
___
Python tracker rep
Steven Bethard steven.beth...@gmail.com added the comment:
That's right, it doesn't support subscripting. The docs are silent on what
namespace is mainly because I don't want to commit to anything other than an
object with attributes. But that could be made clearer in the docs
Steven Bethard steven.beth...@gmail.com added the comment:
2010/5/9 Filip Gruszczyński rep...@bugs.python.org:
So, is there any decision here, so that I could get down to providing better
patch?
I guess I'd like to hear from someone about how these things work in
zsh. If we're going to add
Steven Bethard steven.beth...@gmail.com added the comment:
On Wed, Apr 21, 2010 at 12:36 AM, Andy Buckley rep...@bugs.python.org wrote:
Or to add the option just before arg parsing, if it has not already been
defined?
Something like this was suggested before and it doesn't really work
out
Steven Bethard steven.beth...@gmail.com added the comment:
2010/4/21 Filip Gruszczyński rep...@bugs.python.org:
I don't really understand, why can't we just check if
help-options is provided by the user and add our own,
if it is not?
I'm sure it would be possible to do it this way
Steven Bethard steven.beth...@gmail.com added the comment:
On Wed, Apr 21, 2010 at 12:45 PM, Éric Araujo rep...@bugs.python.org wrote:
An obscure name reusing terms like “compword” that can be found easily in
Python docs and Bash completion docs would be best.
Seems sensible. Does anyone
Steven Bethard steven.beth...@gmail.com added the comment:
Thanks for the patch! One concern I have is that adding --help-options by
default has the potential to break existing code, e.g. if someone using
optparse or argparse was already defining their own --help-options flag. The
backward
Steven Bethard steven.beth...@gmail.com added the comment:
Sorry, what does I'll sit down to mean? Does that mean you're offering to try
to do the argparse patch too? Or that you'd rather someone else do it? (Either
one's fine - I just couldn't tell which you meant
Steven Bethard steven.beth...@gmail.com added the comment:
Someone pointed this out to me earlier:
http://pypi.python.org/pypi/genzshcomp
I believe it's trying to solve the same problem, and claims to work with both
optparse and argparse, so it might be worth looking into what it's doing
===
Announcing argparse 1.1
===
The argparse module provides an easy, declarative interface for
creating command line tools, which knows how to:
* parse the arguments and flags from sys.argv
* convert arg strings into objects for your program
* format and
Steven Bethard steven.beth...@gmail.com added the comment:
@techtonik: If you have a specific feature request for argparse, I
recommend that you file an issue on the argparse tracker[1]. I assure
you that despite the fact that you only have need for a couple of the
constructor parameters
=
Announcing argparse 1.0.1
=
The argparse module provides an easy, declarative interface for
creating command line tools, which knows how to:
* parse the arguments and flags from sys.argv
* convert arg strings into objects for your program
*
=
Announcing argparse 1.0.1
=
The argparse module provides an easy, declarative interface for
creating command line tools, which knows how to:
* parse the arguments and flags from sys.argv
* convert arg strings into objects for your program
*
Steven Bethard steven.beth...@gmail.com added the comment:
@Armin: Doesn't that argument apply to *any* library proposed for
inclusion in the standard library? By which logic we should never add
anything to the standard library ever again. Surely you don't mean that,
so could you be more
Steven Bethard steven.beth...@gmail.com added the comment:
[snip]
Fix packaging and do not dump useless stuff into the standard library to
make it appear more modern. Decentralization is modern, not replacing
modules in the stdlib.
I can respect that viewpoint. So what do you propose to do
===
Announcing argparse 1.0
===
The argparse module provides an easy, declarative interface for
creating command line tools, which knows how to:
* parse the arguments and flags from sys.argv
* convert arg strings into objects for your program
* format and
New submission from Steven Bethard steven.beth...@gmail.com:
Right now, bdist_msi can run out of memory when used for larger
packages. (I found this problem working with NLTK.) The solution is
really simple - just add a db.Commit() so that stuff gets flushed to
disk more often. The attached
Steven Bethard steven.beth...@gmail.com added the comment:
Done in r73499 and r73500. Thanks!
--
resolution: accepted - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6319
Steven Bethard steven.beth...@gmail.com added the comment:
Yeah, the % formatting is an artifact of argparse being around before
str.format was available. If argparse became part of the standard
library, it might be reasonable to change to str.format formatting
instead as part of the move
Steven Bethard steven.beth...@gmail.com added the comment:
On Tue, Jun 9, 2009 at 11:45 PM, Martin v. Löwisrep...@bugs.python.org wrote:
It would be useful if several people could confirm that argparse
is *not* horribly designed.
A totally reasonable request. Anyone willing to evaluate
Steven Bethard steven.beth...@gmail.com added the comment:
I'm happy to contribute argparse to the standard library and volunteer
to maintain it.
For what it's worth, I don't agree that there are already too many
argument parsing libraries in the standard library. I do agree
Steven Bethard steven.beth...@gmail.com added the comment:
@martin:
Thanks! Do I need to do something special to make the merging work
right? Or do I just apply the patch separately to the trunk and the py3k
branche?
Good point about the install script - I think the condition needs
Changes by Steven Bethard steven.beth...@gmail.com:
--
nosy: +bethard
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5926
___
___
Python-bugs-list
Steven Bethard steven.beth...@gmail.com added the comment:
You commit to the trunk, then you do svnmerge merge -rrev in the
3k branch, then svn commit -F svnmerge-something.txt (in case of
conflicts, you fix them first, of course).
Done in r72306 for trunk and r72309 for 3k. Thanks.
I'm
New submission from Steven Bethard steven.beth...@gmail.com:
With issue5311 now resolved, bdist_msi can generate a single MSI that
can install to any number of Python versions (for pure Python modules).
Right now, you can only install or uninstall these MSIs, but it would be
nice to also provide
Steven Bethard steven.beth...@gmail.com added the comment:
A slightly improved patch, using DuplicateFile instead of storing a copy
of each file for each Python version. Should keep the size of the
resulting MSI similar to the size of the currently generated MSIs.
--
Added file: http
Changes by Steven Bethard steven.beth...@gmail.com:
Removed file: http://bugs.python.org/file13847/bdist_msi.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5311
Steven Bethard steven.beth...@gmail.com added the comment:
Ok, one last tiny update that makes sure TARGETDIR is always set to one
of the TARGETDIRX.Ys from a Feature that is actually selected.
I swear I'm done with this now. ;-)
--
Added file: http://bugs.python.org/file13855
Changes by Steven Bethard steven.beth...@gmail.com:
Removed file: http://bugs.python.org/file13854/bdist_msi.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5311
Steven Bethard steven.beth...@gmail.com added the comment:
Here's an MSI generated for the argparse module.
--
Added file: http://bugs.python.org/file13856/argparse-0.9.1.win32.msi
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Steven Bethard steven.beth...@gmail.com added the comment:
Ok, I've been chatting with folks on microsoft.public.platformsdk.msi,
and I think the right approach here is to define a Feature for each
version of Python. Each Feature would install the exact same files, but
to a different Python
Steven Bethard steven.beth...@gmail.com added the comment:
Ok, that was actually easier than I thought it would be. The new patch
introduces properties for each Python version (e.g. TARGETDIR2.4,
PYTHON.MACHINE.2.4, etc.), and disables and hides the features for any
Python versions that aren't
Steven Bethard steven.beth...@gmail.com added the comment:
Ok, I added one final Feature that allows the user to specify an
alternate Python directory. (The PathEdit for specifying the directory
will only display if this Feature is set to be installed.)
I think this patch is pretty much ready
Steven Bethard steven.beth...@gmail.com added the comment:
I'm still stuck on getting the right name to show up in ARP.
Another problem: it seems like we have to update the ProductCode at
runtime as well - otherwise, you can only have one module installed for
all the versions of Python you have
Changes by Steven Bethard steven.beth...@gmail.com:
Removed file: http://bugs.python.org/file13649/bdist_msi.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5311
Steven Bethard steven.beth...@gmail.com added the comment:
Updated the patch to make sure ProductName is set before ValidateProductID.
--
Added file: http://bugs.python.org/file13823/bdist_msi.patch
___
Python tracker rep...@bugs.python.org
http
Steven Bethard steven.beth...@gmail.com added the comment:
I've run into exactly the same thing. The argparse module's
ArgumentError had a message attribute back in Python 2.4, and in
Python 2.6 I get the same warnings Tres is getting.
--
nosy: +bethard
Changes by Steven Bethard steven.beth...@gmail.com:
Removed file: http://bugs.python.org/file13536/PythonVersions.vbs
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5311
Steven Bethard steven.beth...@gmail.com added the comment:
Ok, I've made some progress on this. The attached patch now generates
MSIs which are version agnostic and look up the appropriate Python
version in the registry. Some things still remaining to do:
* The ProductName needs to be modified
Changes by Steven Bethard steven.beth...@gmail.com:
--
nosy: +bethard -bediviere.historic
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1446619
Steven Bethard steven.beth...@gmail.com added the comment:
Thanks for the link. I did play around with that code for quite a while,
and while I'm convinced there's a way to get it to work, I'm still
struggling with it. I believe the attached .vbs file does about what we
need to do, but I think
Steven Bethard steven.beth...@gmail.com added the comment:
My OpenView bug was just a missing Set. The CustomAction does seem to
be correctly gathering the Python paths from the registry and filling
the ListView now. I've still got a couple of errors showing up later in
the process, but I expect
Steven Bethard steven.beth...@gmail.com added the comment:
Ok, so here's what needs to happen to make this work. Note that all of
the following needs to happen at *runtime*, not at the time at which the
.msi is created:
(1) Find all sub-keys of SOFTWARE\Python\PythonCore in the registry
Steven Bethard steven.beth...@gmail.com added the comment:
Here you go. I built the docs with the attached patch, and everything
looks about right to me now.
--
keywords: +patch
Added file: http://bugs.python.org/file13529/python3-bdist-msi-docs.patch
Steven Bethard steven.beth...@gmail.com added the comment:
I'm thinking of stealing/condensing some of the text from here:
http://www.dcl.hpi.uni-potsdam.de/home/loewis/msipackage.html
Does that seem okay? Is any of that text no longer accurate? (E.g. does
bdist_wininst now support Win64
Steven Bethard steven.beth...@gmail.com added the comment:
The original docs request was for a rationale for using bdist_msi
instead of bdist_wininst, but you're right there should be something at
least a little specification-y. And we probably want to keep it pretty
short, so maybe something
Steven Bethard steven.beth...@gmail.com added the comment:
The following 2 line patch adds msi to the list of formats (patch
against py3k trunk). I'm pretty sure this is all that it takes, but I'd
appreciate if someone with more distutils experience could glance at it.
--
keywords
New submission from Steven Bethard steven.beth...@gmail.com:
[Suggested in issue5095 by John Machin]
The 2.6.1 documentation consists of a *single* line:
distutils.command.bdist_msi — Build a Microsoft Installer binary
package. The docs should explain briefly what an msi file is, and why
Steven Bethard steven.beth...@gmail.com added the comment:
You're right that the msi feature could use some more documentation. I
created a documentation feature request: issue5563.
As to why the .msi is specific to the creating version of Python, it's
because no one has written the code
Steven Bethard steven.beth...@gmail.com added the comment:
If no one beats me to it, I plan to do this at PyCon.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5563
New submission from Steven Bethard steven.beth...@gmail.com:
I just ran setup.py bdist_msi with NLTK which is a pure Python
package. You can see the setup.py here:
http://code.google.com/p/nltk/source/browse/trunk/nltk/setup.py. Despite
the fact that NLTK is pure Python, the generated .msi's
Steven Bethard steven.beth...@gmail.com added the comment:
Mostly out of curiosity, why is that? With bdist_wininst, a pure Python
package would generate a version-less installer that could then be used
with any Python version.
___
Python tracker rep
Steven Bethard steven.beth...@gmail.com added the comment:
I'm certainly no Windows API expert, but if no one takes a stab at it
sooner, maybe I can spend some time looking at this during PyCon.
I'm switching the ticket type to a feature request.
--
type: behavior - feature request
New submission from Steven Bethard steven.beth...@gmail.com:
The bdist_msi command is documented in the distutils reference:
http://docs.python.org/distutils/apiref.html#module-distutils.command.bdist_msi
But it does not show up with bdist --help-formats
$ python setup.py bdist --help-formats
Steven Bethard steven.beth...@gmail.com added the comment:
The whole point was to have a function (or class) that accumulates a
sequence and counts it. collections.defaultdict(lambda: 0) doesn't
achieve this on its own because it only knows how to handle sequences of
(key, value):
d
Steven Bethard [EMAIL PROTECTED] added the comment:
Subclassing dict seems like a bad idea. The options value returned by
.parse_args() is not supposed to be dict-like, it's supposed to be
object-like. That is, the natural way of accessing values from it is
through dotted attribute access
Steven Bethard [EMAIL PROTECTED] added the comment:
Why can't you just iterate over ``vars(opts)``?
--
nosy: +bethard
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2444
Steven Bethard [EMAIL PROTECTED] added the comment:
But ``vars()`` is the standard Python mechanism for doing this sort of
thing (that is, treating an object like a dictionary). So, while I
understand that you find iterating over opts to be nicer, calling it
more Pythonic is probably a misuse
Steven Bethard [EMAIL PROTECTED] added the comment:
My experience in the past has been that the optik/optparse maintainer
doesn't often respond to tickets in this tracker, though perhaps that
has changed recently.
__
Tracker [EMAIL PROTECTED]
http
Steven Bethard [EMAIL PROTECTED] added the comment:
I'm attaching a patch that handles object comparisons, type comparisons,
cell comparisons, and dict comparisons. All the tests pass (including
the new ones I've added) but I'd appreciate it if someone could take a
second look.
Other things
Steven Bethard [EMAIL PROTECTED] added the comment:
Resolved in revision 61529.
--
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2342
Steven Bethard [EMAIL PROTECTED] added the comment:
Revision 61529 adds warnings for object, type, cell and dict
comparisons. The code, method and slice warnings are still needed.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2373
Steven Bethard [EMAIL PROTECTED] added the comment:
On Tue, Mar 18, 2008 at 11:57 AM, Benjamin Peterson
[EMAIL PROTECTED] wrote:
Benjamin Peterson [EMAIL PROTECTED] added the comment:
Your patch kicks up warnings in Objects/cellobject.c because
cell_compare returns an int, your patch may
Steven Bethard [EMAIL PROTECTED] added the comment:
So I believe it should be returning -2 instead of NULL. Can someone
verify that -2 means raise an exception for tp_compare?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2373
Steven Bethard [EMAIL PROTECTED] added the comment:
Ok, that warning should be gone now in trunk.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2373
__
___
Python-bugs-list
Steven Bethard [EMAIL PROTECTED] added the comment:
Fair enough. I agree that the deprecated APIs should still be tested.
But there are a lot of other warnings, e.g. where the standard lib uses
``has_key`` instead of ``in``. These should be removed. The only
warnings should be those
Steven Bethard [EMAIL PROTECTED] added the comment:
I took a closer look at sliceobject.c and it looks like both 2.6 and 3.0
compare them basically as tuples. So there don't need to be any warnings
about using and since these are still well defined.
I'll have a patch for codeobject.c
Steven Bethard [EMAIL PROTECTED] added the comment:
Resolved in revision 61570. I can't get svnmerge block to work though.
Since the code and method changes are just backports of Python 3,
someone needs to run ``svnmerge.py block -r 61570``.
__
Tracker [EMAIL
201 - 300 of 1712 matches
Mail list logo
