[issue11472] upload command fails to read auth information from .pypirc
Catherine Devlin added the comment: This blog post http://justcramer.com/2009/04/02/problems-uploading-packages-with-setuptools-on-os-x/ describes working around the same problem by replacing [pypi] in .pypirc with [server-login]. Is that the problem, a change in .pypirc formats? -- nosy: +catherine, catherinedevlin ___ Python tracker <http://bugs.python.org/issue11472> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10087] HTML calendar is broken
Catherine Devlin added the comment: Very simplistic patch to test_calendar.py that adds a test for this fix. This fails on the unpatched trunk b/c the unpatched output begins with b"b'http://bugs.python.org/file22806/test_calendar_byteoutput.patch ___ Python tracker <http://bugs.python.org/issue10087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9650] format codes in time.strptime docstrings
New submission from Catherine Devlin : Is there any reason not to include the strftime formatting codes in the docstrings of time.strftime and time.strptime? >>> print time.strftime.__doc__ strftime(format[, tuple]) -> string Convert a time tuple to a string according to a format specification. See the library reference manual for formatting codes. When the time tuple is not present, current time as returned by localtime() is used. Sending users to look up such a basic, frequently-used, hard-to-remember set of codes in the docs every single time seems unfriendly. Even a tightly abbreviated list would be very convenient. -- components: Library (Lib) messages: 114427 nosy: catherine priority: normal severity: normal status: open title: format codes in time.strptime docstrings type: feature request versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue9650> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9650] format codes in time.strptime docstrings
Catherine Devlin added the comment: > There is the non-zero cost of keeping two copies of that bit of > information in-sync with each other (and the code). That's true, but how often do the strftime format codes change? I'd be happy to personally volunteer to keep them in synch. I suspect it would take me half an hour once or even twice per decade. > I believe the reason is that time.strftime behavior is platform dependent, so > "man strftime" is likely to produce more relevant documentation than "pydoc > time.strftime". So everything I've written with strftime is not cross-platform after all? Eek. Anyway, why couldn't the docstring do the same thing the Python docs do - report the ANSI codes, and mention that platform-specific variations are possible? Alternately, simply including a suggestion to ``man strftime`` in the docs would be a good start, since I had no idea about that (and I doubt I'm the only one). Of course, it's useless advice for Windows users. > Note the source at one of these sites: > "Source: Python’s strftime documentation." :-) Of course - the point is that people are feeling enough pain in drilling down to the right place in the Python documentation that a convenient designated URL seems attractive by comparison. -- ___ Python tracker <http://bugs.python.org/issue9650> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9650] format codes in time.strptime docstrings
Catherine Devlin added the comment: > Did my suggestion to alter pydoc output so it always contains a link to the > enclosing module's documentation not seem like a reasonable compromise? I actually don't understand how that would help. The ``pydoc time`` output doesn't include any information about the formatting codes (at least, on my system). Also, ``pydoc`` isn't available on Windows systems, is it? It isn't on mine; is that a quirk of my setup? > Another problem with embedding the format codes in the docstring is that it > opens up a Pandora's box of other stuff that might be reasonable to include > in other docstrings, but should probably just be documented in one place > (perhaps with references elsewhere). For example, maybe we should add the > list of signals to the docstrings for signal.signal and os.kill (pretty > platform-dependent) or add all the format possibilities to the docstring for > the format() builtin (brand new and probably not well-known to very many > users). I'm sure there are other candidates. It can be difficult to know > where to draw the line. Yes, certainly, in one place - but isn't it logical for the docstring to be that one place? Universal convenient access, and the least risk that it will get out of synch with the code. Here's where I would suggest drawing the line: if the method is unusable without the information, and it's not easy to guess or remember, and it's relatively concise, it should be in the docstring. Is that a Pandora's box or a set of good suggestions? :) Probably not stuff that is strongly platform-dependent, but for format(), for example, I think that's a good idea. I don't think there's anything wrong with setting a precedent that could lead to more useful docstrings in several different places. Anyway, I would settle for a suggestion in the docstring to run ``man strftime``, but only if there's some Windows equivalent; does anybody know of one? -- ___ Python tracker <http://bugs.python.org/issue9650> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): allow removing empty strings (when sep is not None)
Change by Catherine Devlin : -- nosy: +Catherine.Devlin nosy_count: 11.0 -> 12.0 pull_requests: +24813 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/26196 ___ Python tracker <https://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): allow removing empty strings (when sep is not None)
Catherine Devlin added the comment: @ZackerySpytz - I made https://github.com/python/cpython/pull/26196 with a test for the desired behavior; hopefully it helps. I could try to adapt Barry's old patch myself, but it's probably better if somebody C-competent does so... -- ___ Python tracker <https://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4928] tempfile.NamedTemporaryFile: automatic cleanup by OS
Change by Catherine Devlin : -- keywords: +patch nosy: +Catherine.Devlin nosy_count: 8.0 -> 9.0 pull_requests: +24815 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/26198 ___ Python tracker <https://bugs.python.org/issue4928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35889] sqlite3.Row doesn't have useful repr
Catherine Devlin added the comment: What about a __repr__ that includes the primary key value(s) (for tables where that is defined)? That would be useful and informative, and also generally short. -- nosy: +Catherine.Devlin ___ Python tracker <https://bugs.python.org/issue35889> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20131] warnings module offers no documented, programmatic way to reset "seen-warning" flag
Catherine Devlin added the comment:
I think that it's possible to get the desired behavior by setting a filter to
"always".
```
> cat warnme.py
import warnings
for i in range(3):
warnings.warn("oh noes!")
> python warnme.py
warnme.py:4: UserWarning: oh noes!
warnings.warn("oh noes!")
> cat warnme2.py
import warnings
warnings.simplefilter("always")
for i in range(3):
warnings.warn("oh noes!")
> python warnme2.py
warnme2.py:5: UserWarning: oh noes!
warnings.warn("oh noes!")
warnme2.py:5: UserWarning: oh noes!
warnings.warn("oh noes!")
warnme2.py:5: UserWarning: oh noes!
warnings.warn("oh noes!")
```
Does that meet the need?
--
nosy: +Catherine.Devlin
___
Python tracker
<https://bugs.python.org/issue20131>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24929] _strptime.TimeRE should not enforce range in regex
Change by Catherine Devlin : -- keywords: +patch nosy: +Catherine.Devlin nosy_count: 2.0 -> 3.0 pull_requests: +24832 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/26215 ___ Python tracker <https://bugs.python.org/issue24929> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24929] _strptime.TimeRE should not enforce range in regex
Catherine Devlin added the comment: Can we close the ticket? It doesn't sound like we're going to go with anything like this approach. If there's a good place to record the general ambitions (better strptime tests, more clear strptime errors), that would be good, but I don't think we use tickets for that. -- ___ Python tracker <https://bugs.python.org/issue24929> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24929] _strptime.TimeRE should not enforce range in regex
Catherine Devlin added the comment: Thinking about this a little more... I suggest that slowing down execution shouldn't be a worry in this case, because trying to parse a garbage string into a date shouldn't be something code is doing zillions of times, and if it is, being slow isn't a terrible thing. It should be the exception (so to speak) and not the rule, and thus not something we should worry about optimizing for. That said, I can see not wanting to rely on throwing low-level errors that are outside Python's direct control. (In fact, the PR I wrote didn't account for the OS-dependent nature of those messages, so if we decide to go ahead after all I'll need to make my PR account for that.) If that is enough reason to reject the change, I'm content with that. One way or the other, I would love to get this out of "Open" status - if we want to just close it as-is, I'll be satisfied. -- nosy: +catherinedevlin ___ Python tracker <https://bugs.python.org/issue24929> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44208] argparse: Accept option without needing to distinguish "-" from "_" in arg_string
Catherine Devlin added the comment: Your PR doesn't include any tests... but I like the idea enough to create the tests for you if you prefer. However, first I'd like to see whether the core devs like the idea. I could see saying either "yes, why not make things easy" or "no, there should be only one way to do it". -- nosy: +catherinedevlin ___ Python tracker <https://bugs.python.org/issue44208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44208] argparse: Accept option without needing to distinguish "-" from "_" in arg_string
Catherine Devlin added the comment: All that said, it's easy to imagine a PyPI package that would give this functionality for those who want it. Maybe even one that could also alter the behavior of Click and Typer. If you want to go that route, let me know. -- ___ Python tracker <https://bugs.python.org/issue44208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30438] tarfile would fail to extract tarballs with files under R/O directories
Catherine Devlin added the comment: I confirmed the error, and that doing the corresponding tar/untar cycle with the command-line `tar` utility succeeds. issue_30438_test.patch adds a unittest version of Yaroslav's demo file to test_tarfile.py. (It's irrelevant if the PR is merged.) This doesn't actually include a fix. Issue should remain open. -- keywords: +patch nosy: +Catherine.Devlin pull_requests: +1850 Added file: http://bugs.python.org/file46890/issue_30438_test.patch ___ Python tracker <http://bugs.python.org/issue30438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30438] tarfile would fail to extract tarballs with files under R/O directories
Changes by Catherine Devlin : Removed file: http://bugs.python.org/file46890/issue_30438_test.patch ___ Python tracker <http://bugs.python.org/issue30438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30438] tarfile would fail to extract tarballs with files under R/O directories
Catherine Devlin added the comment:
I apologize, I retract my earlier comment - I believe both Yaroslav and I were
confused about the nature of the problem. I think it's not related to
permissions at all, but to adding a file to the tarfile twice.
To see this, use `tarfilero.py` as provided by Yaroslav, but comment out the
`tar.add('sample/rodir/file')` line (line 16) and run it - everything works
normally, and the `rodir/file` is present.
It appears that adding the directory to the tarfile also adds the file within
the directory, and adding the file individually creates a second reference to
the file. When expanding, `tarfile` attempts to create the file twice, and the
second attempt fails because a file by that name already exists.
I still think this is a bug - perhaps re-adding a file already present in a
tarfile should throw an error, or silently do nothing without adding a second
reference to the file, or at least the error message when trying to expand a
file into a path that is blocked by a file already present should give a more
informative error. I will look for existing tickets along those lines.
--
___
Python tracker
<http://bugs.python.org/issue30438>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30438] tarfile would fail to extract tarballs with files under R/O directories (twice)
Changes by Catherine Devlin : -- pull_requests: +1892 ___ Python tracker <http://bugs.python.org/issue30438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30438] tarfile would fail to extract tarballs with files under R/O directories (twice)
Catherine Devlin added the comment: Okay, the problem is a little more specific than my last message suggested, but also a little less specific than the original report. A "PermissionError: [Errno 13] Permission denied" is thrown when expanding a tarfile to which a file had been added more than once, *if* the file is not writeable. (tarfile expands the file twice, but the second time finds a non-writeable file in the way.) This was true for Yaroslav's case because his file was added once as its directory was added, and again when the file was added directly. The permission of the parent directory does not matter after all. -- ___ Python tracker <http://bugs.python.org/issue30438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30438] tarfile would fail to extract tarballs with files under R/O directories (twice)
Catherine Devlin added the comment: My last commit to the PR includes a fix by delaying setting permission to all files, not just to directories, in .extractall(). It might be better to catch the problem during .add instead, preventing tarring multiple copies, but I found subtle difficulties with that approach. (Do we have a foolproof way to establish that a second addition is a duplicate? What if the filename and path is the same, but the file has been changed since last time it was added to the tar?) This solution uses code that's already present. -- ___ Python tracker <http://bugs.python.org/issue30438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33233] Suggest third-party cmd2 module as alternative to cmd
Catherine Devlin added the comment: Hi, everybody! I really appreciate the kind words about cmd2. For several years now, Todd Leonhardt has been cmd2's primary maintainer, so I may be speaking out of turn. But, before I wanted to let it get within screaming distance of the standard library, I would want to refactor it like mad; maybe even remove some features that were created more in a spirit of gee-whiz-I-can-do-this than real need. Todd and I have worked a little on such a refactor, but even once we make time to actually complete it, that would make cmd2 by definition too unstable until the refactored version itself had earned some grey hair. Also, cmd2 depends on pyparsing, which is itself unlikely to be in the standard library. I think a "see also" list attached to standard library module docs would be great, and if this helps nucleate a decision about whether/how to do that for a bunch of modules, that would be great. -- nosy: +catherinedevlin ___ Python tracker <https://bugs.python.org/issue33233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1666318] shutil.copytree doesn't give control over directory permissions
Catherine Devlin added the comment: Attaching a test that verifies that shutil.copytree is, in fact, preserving permissions (as of Python 3.4.0a0 (default:66a3dc613627, Jul 27 2013, 21:23:10) ) As far as I can tell this can be closed. -- nosy: +catherinedevlin Added file: http://bugs.python.org/file31081/test1666318.patch ___ Python tracker <http://bugs.python.org/issue1666318> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1666318] shutil.copytree doesn't give control over directory permissions
Catherine Devlin added the comment: Thanks, Antoine - I've signed and submitted the Contributor's Agreement. -- Added file: http://bugs.python.org/file31104/Python Contributor Agreement Form - signed.pdf ___ Python tracker <http://bugs.python.org/issue1666318> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1666318] shutil.copytree doesn't give control over directory permissions
Catherine Devlin added the comment: Attaching new patch incorporating Vajrasky's suggestion -- Added file: http://bugs.python.org/file31316/test1666318.patch ___ Python tracker <http://bugs.python.org/issue1666318> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6471] errno and strerror attributes incorrectly set on socket errors wrapped by urllib
Catherine Devlin added the comment: It's very hard to tell what ought to be done here, since Lib/urllib/request.py throws URLErrors with a great variety of order and number of arguments, and it's not clear how URLError (in Lib/urllib/error.py) intends to handle them. However, in this case, AbstractHTTPHandler.do_open is instantiating URLError with another exception instance, and that exception contains .errno and .strerror. URLError puts the entire error instance into ``reason``, where the information is hidden away as .reason.strno and .reason.strerror. In the name of keeping this information available rather than hiding it, I'm attaching a patch that adds to URLError.__init__: if hasattr(reason, "errno"): self.errno = reason.errno if hasattr(reason, "strerror"): self.strerror = reason.strerror Again, I'm not sure this is the most logical approach because I can't find a consistent pattern in the ways URLError is instantiated. -- keywords: +patch nosy: +catherine Added file: http://bugs.python.org/file26559/keeperrdata.patch ___ Python tracker <http://bugs.python.org/issue6471> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13214] Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s)
Catherine Devlin added the comment: Needed to update the patch slightly for Python 3; now that filter() returns an iterator, ``do_help``'s call to names = self.get_names() followed by names.sort() was throwing an error, so I changed get_names to return a list. -- nosy: +Catherine.Devlin Added file: http://bugs.python.org/file26593/python-cmd-better-filtering-py3.patch ___ Python tracker <http://bugs.python.org/issue13214> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13214] Cmd: list available completions from the cmd.Cmd subclass and filter out EOF handler(s)
Catherine Devlin added the comment: Change to test_cmd.py to test for help displaying the name of the registered subcommand (as well as a simple test for the basic operation of the registered sub-CLI). -- Added file: http://bugs.python.org/file26594/test_cmd.patch ___ Python tracker <http://bugs.python.org/issue13214> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8620] wrong truncation of last line in cmd.Cmd
Catherine Devlin added the comment: Patch created live during PyOhio 2010 "Teach Me Python Bugfixing" session! -- nosy: +catherine Added file: http://bugs.python.org/file18294/cmd-noeol-test.fix.patch ___ Python tracker <http://bugs.python.org/issue8620> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8620] wrong truncation of last line in cmd.Cmd
Catherine Devlin added the comment: same patch, stripped of trailing spaces -- Added file: http://bugs.python.org/file18297/cmd-noeol-test.fix.patch ___ Python tracker <http://bugs.python.org/issue8620> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Changes by Catherine Devlin : -- nosy: -ted.turocy Added file: http://bugs.python.org/file18320/argparse_test.patch ___ Python tracker <http://bugs.python.org/issue9444> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9444] argparse does not honor prefix_chars when adding default options
Catherine Devlin added the comment: Attached a unit test patch corresponding to Ted's patch. http://bugs.python.org/file18320/argparse_test.patch -- nosy: +catherine ___ Python tracker <http://bugs.python.org/issue9444> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9348] Calling argparse's add_argument with the wrong number of metavars causes delayed error message
Catherine Devlin added the comment: I'm attaching a unit test patch that does something vaguely like Steven suggests. It definitely needs review. Also, I'm assuming that it's OK to specify *fewer* metavars than nargs, just not more... but I'm not sure about that. -- keywords: +patch nosy: +catherine Added file: http://bugs.python.org/file18327/wrong_metavars_test.patch ___ Python tracker <http://bugs.python.org/issue9348> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9338] argparse optionals with nargs='+' can't be followed by positionals
Catherine Devlin added the comment: Here's a unit test for the simplest cases. -- keywords: +patch nosy: +catherine Added file: http://bugs.python.org/file18328/test_pos_after_var_args.patch ___ Python tracker <http://bugs.python.org/issue9338> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9352] argparse eats characters when parsing multiple merged short options
Catherine Devlin added the comment: Attaching a test to verify parse failure on mismatched prefix (-abc or +abc). Steven's patch makes it pass. -- nosy: +catherine versions: -Python 2.7, Python 3.2 Added file: http://bugs.python.org/file18342/test_multiple_short_same_prefix.patch ___ Python tracker <http://bugs.python.org/issue9352> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9352] argparse eats characters when parsing multiple merged short options
Catherine Devlin added the comment: Updated Steven's patch; no changes, but now it knows the new context so that ``patch -p0`` won't fail. -- Added file: http://bugs.python.org/file18343/multiple_short_same_prefix_new.patch ___ Python tracker <http://bugs.python.org/issue9352> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9340] argparse parse_known_args does not work with subparsers
Catherine Devlin added the comment: Some basic unit tests for parse_known_args on a subparser. -- keywords: +patch nosy: +catherine Added file: http://bugs.python.org/file18344/test_subparser_parse_known_args.patch ___ Python tracker <http://bugs.python.org/issue9340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9340] argparse parse_known_args does not work with subparsers
Changes by Catherine Devlin : Removed file: http://bugs.python.org/file18344/test_subparser_parse_known_args.patch ___ Python tracker <http://bugs.python.org/issue9340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9340] argparse parse_known_args does not work with subparsers
Catherine Devlin added the comment: Some simple unit tests for parse_known_args on a parser with a subparser. They are indeed failing on the trunk. -- Added file: http://bugs.python.org/file18346/test_subparser_parse_known_args.patch ___ Python tracker <http://bugs.python.org/issue9340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9340] argparse parse_known_args does not work with subparsers
Catherine Devlin added the comment: This patch fixes it with a fourth approach: if unrecognized arguments are found during subparser parsing, information about them is inserted into the namespace (under "._unrecognized"), and the decision about whether to exit is deferred. When top-level parsing is finished, those recorded unrecognized args are added to whatever was found by the main parser. It passes the tests I submitted yesterday. -- Added file: http://bugs.python.org/file18388/unrecognized_args_defer_exit.patch ___ Python tracker <http://bugs.python.org/issue9340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9348] Calling argparse's add_argument with the wrong number of metavars causes delayed error message
Catherine Devlin added the comment: Thanks for the correction, Steven. This unit test matches your description. Use it instead of my earlier submission. -- Added file: http://bugs.python.org/file18390/wrong_metavars_test_corrected.patch ___ Python tracker <http://bugs.python.org/issue9348> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9355] argparse add_mutually_exclusive_group more than once has incorrectly formatted help
Catherine Devlin added the comment: Unit test for Drake's patch -- nosy: +catherine Added file: http://bugs.python.org/file18392/test_mutually_exclusive.patch ___ Python tracker <http://bugs.python.org/issue9355> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9355] argparse add_mutually_exclusive_group more than once has incorrectly formatted help
Catherine Devlin added the comment: copy of Drake's argparse.diff - same patch, just has less specific diff header info (because ``patch -p0 < argparse.diff`` failed on my machine) -- Added file: http://bugs.python.org/file18393/mutually_exclusive_help.patch ___ Python tracker <http://bugs.python.org/issue9355> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24518] json.dumps should accept key function for ``sort_keys``
New submission from Catherine Devlin: Right now, json.dumps can be called with True or False, but it would be easy to also support accepting a key function, which then could be used to control the order of keys arbitrarily in the serialized JSON output. -- components: Library (Lib) messages: 245874 nosy: catherinedevlin priority: normal severity: normal status: open title: json.dumps should accept key function for ``sort_keys`` type: enhancement versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue24518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24518] json.dumps should accept key function for ``sort_keys``
Catherine Devlin added the comment: Implementation for the enhancement. Includes tests. -- keywords: +patch Added file: http://bugs.python.org/file39823/json_callable_sort_24518.patch ___ Python tracker <http://bugs.python.org/issue24518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
