Chris Jerdonek added the comment:
Thanks for waiting and for posting the patches here. I think the second patch
2-move_two_sections.diff should be committed now, along with making Working
with Mercurial a higher-level header (as it is done in the aggregate patch).
This will separate
New submission from Chris Jerdonek:
The documentation guidelines in the devguide list a convention for section
headers:
http://docs.python.org/devguide/documenting.html#sections
The current wording, however, can be interpreted to mean that this convention
is always (and should always
Chris Jerdonek added the comment:
It can just be changed to being a suggestion as opposed to the convention
that we use.
I created issue 17270 for this.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17109
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17270
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17203
Chris Jerdonek added the comment:
For reasons I stated above, I think it will help to break this issue into
smaller, self-contained parts as we go -- even if some of the issues turn out
to be short-lived.
For example, an issue can be created for adding to the docs a section on how to
set up
Chris Jerdonek added the comment:
The Clones setup section is not about how to set up a clone, but how do
I do these steps depending on the specific setup I'm using (single or
multiple clones).
Then the section should be called something like Cloning approaches rather
than Clones setup
Chris Jerdonek added the comment:
Adding a patch to fix this issue.
I had tried this, but doesn't this make the contents in the left side bar
unwieldy (and perhaps also on the devguide index page) -- is that what we want?
I was under the assumption that the purpose of the tocdepth directive
Chris Jerdonek added the comment:
Looks like it's because highlightlang:: c is at the top.
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17256
Chris Jerdonek added the comment:
If we can promise not to use it in the from-import case :) I'm okay with the
more specific name (in fact it is preferable). From Brett's response, it
sounds like we have flexibility there and don't need it to be the same? For
from-import I would prefer
Chris Jerdonek added the comment:
This is not satisfactory. I would prefer:
import argparse
argparser = argparse.ArgumentParser()
subparsers = argparser.add_subparsers('cmd1') % name here
Have you tried passing by keyword?
subparsers = argparser.add_subparsers(dest='cmd1')
It seems
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +bethard, chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17250
Chris Jerdonek added the comment:
I noticed this before and wasn't able to fix it after trying a few things. I
wonder if this is a limitation or bug in Sphinx. At the top, the FAQ page has--
:tocdepth: 2
Levels beyond 2 are getting numbered 25 (the number of the top level) instead
Chris Jerdonek added the comment:
Levels beyond 2 are getting numbered 25 (the number of the top level) instead
of having their numbering suppressed (as I would expect it to).
Actually, what I meant to say is that I would expect the tocdepth to affect
only the level of the table of contents
Chris Jerdonek added the comment:
from foo import bar
Here bar can be not module, but an attribute of foo (for example, os.path).
Serhiy: What exception is raised in that situation is controlled by the eval
loop, not importlib so that would be a separate change.
Just to clarify from
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17227
___
___
Python
Chris Jerdonek added the comment:
Thanks, one patch should be fine, though the change should be applied to all
branches.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17203
New submission from Chris Jerdonek:
This issue is to add to argparse's add_mutually_exclusive_group() method
support for passing a title and description. From the argparse docs:
Note that currently mutually exclusive argument groups do not support the
title and description arguments
Chris Jerdonek added the comment:
I commented above that the tests are not very DRY though. Shouldn't there be
tests to check that the documented behavior is correct?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16278
Chris Jerdonek added the comment:
Senthil, in my experience, whenever documentation is added that documents new
aspects of behavior (e.g. is not just a rewording of existing documentation),
tests are always added simultaneously (if not already present) to ensure that
the code doesn't regress
Chris Jerdonek added the comment:
If it would help I could submit a single patch.
Yes, a single patch is best. One way to make code more DRY is refactoring to
use helper functions as needed (i.e. same code in multiple places - one helper
function
Chris Jerdonek added the comment:
The number of test cases isn't the problem. Having more but finer-grained test
cases is usually preferred in fact. It's just that the test cases should be
sharing code where possible so that they're shorter and easy to see how they
differ from one another
New submission from Chris Jerdonek:
Currently, unittest's discovery command-line documentation:
http://docs.python.org/dev/library/unittest.html#test-discovery
does not include the long option names (--start-directory, --pattern, and
--top-level-directory):
http://hg.python.org/cpython/file
New submission from Chris Jerdonek:
Currently, argparser's subparsers.add_parser() method (for adding sub-commands)
takes the following input:
This object has a single method, add_parser(), which takes a command name and
any ArgumentParser constructor arguments, and returns an ArgumentParser
Chris Jerdonek added the comment:
Thanks a lot for taking care of this issue, Michael.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17052
Chris Jerdonek added the comment:
what if there are 500 subtests in a loop and you don't want 500 failures to
be
registered for that test case?
Parametered tests have the same issue. In this case you simply don't use
subtests
or test cases.
Right, but then you lose out on both
Chris Jerdonek added the comment:
I'm still opposed to exposing these features only together. Annotating the
failure message with parametrization data is useful in its own right, but what
if there are 500 subtests in a loop and you don't want 500 failures to be
registered for that test case
Chris Jerdonek added the comment:
Michael, was this implemented correctly? Loader should be a callable (e.g. a
class), but self.testLoader is an instance (it defaults to
loader.defaultTestLoader, which equals loader.TestLoader()):
http://hg.python.org/cpython/file/b53b029895df/Lib/unittest
Chris Jerdonek added the comment:
It seems like the last patch (subtests5.patch) dropped the parameter data from
the failure output as described in the docs. For example, the example in the
docs yields the following:
FAIL: test_even (__main__.NumbersTest)
instead of the documented
Chris Jerdonek added the comment:
+- Issue #17502: unittest discovery should use self.testLoader.
Also, this should read Issue #17052.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17052
Chris Jerdonek added the comment:
See issue 16926 for another issue about using -r with register.
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17144
Chris Jerdonek added the comment:
Danilo, does this work any better?
$ python setup.py sdist register -r local upload
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17144
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +bethard, chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17113
Chris Jerdonek added the comment:
Never mind :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17109
___
___
Python-bugs-list mailing list
Chris Jerdonek added the comment:
How does the + level relate to the convention described here?
http://docs.python.org/devguide/documenting.html#sections
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Chris Jerdonek added the comment:
I see why I was confused. The ~'s are different from -'s. The tilde level
isn't listed in our devguide conventions.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17109
Chris Jerdonek added the comment:
I think the guidance is still helpful. I have referred to it often. It can
just be changed to being a suggestion as opposed to the convention that we
use.
--
___
Python tracker rep...@bugs.python.org
http
Chris Jerdonek added the comment:
See also issue 17087 which is essentially the same issue but for match objects.
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13592
Chris Jerdonek added the comment:
I would like to request again that these changes be proposed and committed in
smaller chunks.
I have comments of a basic nature that would be much easier to discuss and
address in the context of smaller patches. Otherwise, the discussion isn't
manageable
Chris Jerdonek added the comment:
My understanding is that the commits are all or nothing. In other words, they
all need to be reviewed before any are committed. I would like for the patches
to be reviewed and committed individually so the review process is more
manageable and people can
Chris Jerdonek added the comment:
Also, I would be happy to start that process using the work that you have done.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
Chris Jerdonek added the comment:
I see ways that the changes can be proposed and committed incrementally. I can
start proposing those.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14468
Chris Jerdonek added the comment:
The point is to allow a manageable discussion to take place around points of
contention while making forward commit progress along the way. I have
suggestions right now, but the current massive batch of changes makes it too
unwieldy. The incremental commits
Chris Jerdonek added the comment:
I meant to comment on the patch earlier.
The fix here isn't as simple as I had originally suggested. The patch has to
be constructed more carefully to be more fully backwards compatible. For
example, it shouldn't break code that imports DEBUG from modules
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
keywords: -easy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16989
___
___
Python-bugs
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
resolution: - invalid
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17081
Chris Jerdonek added the comment:
I am concerned that this feature changes the TestResult API in a backwards
incompatible way.
My suggestion to add the original TestCase object to TestResult.errors, etc.
instead and add the extra failure data to the longDescription would address
Chris Jerdonek added the comment:
I've already replied to all this.
You didn't respond to the idea of exposing both features separately after
saying you didn't understand what I meant and saying that they were pointless
and didn't make sense. So I explained and also proposed a specific API
Chris Jerdonek added the comment:
Is this a duplicate of issue 13592?
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17087
Chris Jerdonek added the comment:
This has already been proposed in issue 15580. By the way, you don't always
want to replace true with ``True``. The former has a different
connotation/meaning which is boolean true rather than the object True.
--
nosy: +chris.jerdonek
resolution
Chris Jerdonek added the comment:
This documentation states that libraries can turn off logging by adding a
NullHandler:
I don't think that's what the documentation says. It says, If for some reason
you don’t want these messages printed *in the absence of any logging
configuration* [my
Chris Jerdonek added the comment:
Yes, I know. I went through all the occurrences one by one, and I tried to
take that into account.
See issue 4945 for a discussion like this. Might be relevant to what you have
in mind.
--
___
Python tracker
Chris Jerdonek added the comment:
This has already been proposed in issue 15580.
By the way, I should have said something along the same lines. Issue 15580
is about eliminating uses of :const:`None`, etc, whereas this targets a
different case. But it is similar in scope so the same
Chris Jerdonek added the comment:
It might be worth clarifying in the devguide then if True/False/etc shouldn't
be treated differently from other things. The current wording suggests that
links shouldn't be used at all in those cases (e.g. given that they’re
fundamental to the language
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14037
___
___
Python
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14039
___
___
Python
Chris Jerdonek added the comment:
Have you tried setting the metavar property on the return value of
add_subparsers()? I tried this, and it seems to work.
It looks like the logic for _metavar_formatter() is the same no matter what the
action type (specifically _SubParsersAction in this case
Chris Jerdonek added the comment:
Actually, it looks like add_subparsers() may already support passing a metavar
argument, but it's just not documented?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14039
Chris Jerdonek added the comment:
I will at least! :) I noticed the issue after trying to use unittest test
discovery with a custom loader. Fortunately, there is at least this
work-around (though it relies on an implementation detail):
class MyTestProgram(unittest.TestProgram
Chris Jerdonek added the comment:
Whichever solution you pick for the test issue, I would at least add a code
comment explaining that the test return value needs to be garbage collected and
why, etc. and probably reference this issue.
If anyone thinks the 'ReapedSuite' class (or a better
Chris Jerdonek added the comment:
1. Easily append data to failure messages coming from a block of asserts
2. Continue running a test case after a failure from a block of asserts
Both of these seem independently useful and more generally applicable,
I don't understand what you mean. 1
New submission from Chris Jerdonek:
Works:
p = ArgumentParser(prog='test.py')
p.add_argument('pos')
p.add_argument('remainder', nargs=argparse.REMAINDER)
p.parse_args(['abc', '--def'])
Namespace(pos='abc', remainder=['--def'])
Doesn't work:
p = ArgumentParser(prog='test.py
Chris Jerdonek added the comment:
See also issue 17050 for a reduced/simple case where argparse.REMAINDER doesn't
work (the case of the first argument being argparse.REMAINDER).
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http
New submission from Chris Jerdonek:
The _do_discovery() method of unittest.TestProgram:
def _do_discovery(self, argv, Loader=loader.TestLoader):
(from http://hg.python.org/cpython/file/2cf89e2e6247/Lib/unittest/main.py#l222 )
should be using self.testLoader instead of loader.TestLoader
Chris Jerdonek added the comment:
After thinking about this more, it seems this lets you do two orthogonal things:
1. Easily append data to failure messages coming from a block of asserts
2. Continue running a test case after a failure from a block of asserts
Both of these seem independently
Chris Jerdonek added the comment:
Okay, I think I understand the issue better now. The threading._dangling
warning happens because when leaving the saved_test_environment context manager
in regrtest:
http://hg.python.org/cpython/file/fcdb35b114ab/Lib/test/regrtest.py#l1271
the context
Chris Jerdonek added the comment:
the choice part of the error message (passed to ArgumentError) will just be
'invalid choice: value'.
That's right. With the patch it looks like this:
p = argparse.ArgumentParser(prog='test.py')
p.add_argument('--foo', choices=c)
p.parse_args(['--foo
Chris Jerdonek added the comment:
I looked into this a bit. It seems like this is because with the patch, the
call to loader.loadTestsFromModule(the_module) inside regrtest comes before
the try-finally:
http://hg.python.org/cpython/file/fcdb35b114ab/Lib/test/regrtest.py#l1277
whereas
Chris Jerdonek added the comment:
I confirmed the above by changing regrtest as follows in the patch (moving the
decorator from load_tests()), and trying both placements of the
loadTestsFromModule() line. One gives the warning and one does not:
if test_runner is None:
loader
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9253
___
___
Python
Chris Jerdonek added the comment:
It might be better if the revision link was separate from the
description text.
I did the opposite -- I left the revision link there and created a separated
link to the issue at the end of the description.
Some downsides of the selected approach
New submission from Chris Jerdonek:
Here are some suggestions of things to clarify in the logging documentation
after consulting it as an end-user:
1. Clarify in Logger.filter(), Handler.filter(), and probably also in the
Filter section that the case of more than filter behaves as follows
Chris Jerdonek added the comment:
Great, that looks a lot better. Thanks!
A couple comments though:
+ .. note:: If you attach a handler to several loggers, it may emit the same
+ record multiple times. In general, you should not need to attach a
+ handler to more than one logger
Chris Jerdonek added the comment:
I added some Rietveld comments.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16970
___
___
Python-bugs-list
Chris Jerdonek added the comment:
This was fixed a year and a half ago by issue 12351. For example, see:
http://docs.python.org/3/library/crypto.html
--
nosy: +chris.jerdonek
resolution: - out of date
stage: - committed/rejected
status: open - closed
superseder: - Update URL
Chris Jerdonek added the comment:
There are also test cases with a string being passed for choices.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16977
Chris Jerdonek added the comment:
Here is a patch for discussion that allows non-iterable choices with or without
metavar. It refactors as suggested. However, the patch does not yet have
tests.
Does the test suite already have a testcase already for non-iterable choices
+ metavar
Chris Jerdonek added the comment:
See issue 16468 for why that won't work in general.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16977
Chris Jerdonek added the comment:
When choices isn't iterable but supports the in operator, e.g.
class MyChoices(object):
def __contains__(self, item):
return True
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Chris Jerdonek added the comment:
Nice/elegant idea. A couple comments:
(1) What will be the semantics of TestCase/subtest failures? Currently, it
looks like each subtest failure registers as an additional failure, meaning
that the number of test failures can exceed the number of test cases
Chris Jerdonek added the comment:
Either way, something isn't right about how it's integrated now. With
the patch, this:
@unittest.expectedFailure
def test(self):
with self.subTest():
self.assertEqual(0, 1)
gives: FAILED (failures=1, unexpected successes=1
Chris Jerdonek added the comment:
This wasn't just in the documentation. It was the *first* example of how to
use the choices argument out of the two examples in that section (from the time
Python first adopted argparse and before):
16.4.3.7. choices
Some command-line arguments should
Chris Jerdonek added the comment:
Thanks for the patch. I will take a look. And good observation re: PARSER.
Can you open a separate documentation issue for that where it can be discussed?
--
___
Python tracker rep...@bugs.python.org
http
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16988
___
___
Python
New submission from Chris Jerdonek:
This issue is to allow distutils's debug mode [1] to be enabled more easily
(e.g. programmatically).
Currently, for example, distutils.core does the following:
from distutils.debug import DEBUG
(from http://hg.python.org/cpython/file/cb297930d2cf/Lib
Chris Jerdonek added the comment:
I have a new suggestion that I hope will satisfy Terry.
After looking at the code more, I noticed that add_argument() does currently
work for non-iterable choices provided that metavar is passed. This was also
noted in the report for the duplicate issue
Chris Jerdonek added the comment:
Actually, let me relax (1). We can just use what the argparse code calls the
default_metavar in that case (which it constructs from the argument name).
The important thing for me is not displaying the str/repr when it might not be
intended
Chris Jerdonek added the comment:
Adding a failing test. I will supply a patch shortly.
--
keywords: +patch
stage: - needs patch
Added file: http://bugs.python.org/file28731/issue-16468-1.patch
___
Python tracker rep...@bugs.python.org
http
Chris Jerdonek added the comment:
Attaching patch. With this patch, passing a non-iterable choices argument to
parser.add_argument() raises (for example):
Traceback (most recent call last):
...
File .../Lib/argparse.py, line 558, in _metavar_formatter
choice_strs = [str(choice
Chris Jerdonek added the comment:
Slight doc tweak: s/container/sequence/.
--
Added file: http://bugs.python.org/file28735/issue-16468-3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16468
New submission from Chris Jerdonek:
parser = argparse.ArgumentParser()
parser.add_argument('foo', nargs='a')
...
File .../Lib/argparse.py, line 1333, in add_argument
raise ValueError(length of metavar tuple does not match nargs)
ValueError: length of metavar tuple does not match nargs
Chris Jerdonek added the comment:
Sounds fine. Does that mean a test should still be added for the message? I
was never clear on this because on the one hand we want to be sure we use the
right message (and that we're actually fixing the issue), but on the other hand
we don't want
Chris Jerdonek added the comment:
I guess another option would be to mark the test CPython-only.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16468
Chris Jerdonek added the comment:
I don't disagree that this feature could be useful. I'm just not sure it
should go into a maintenance release. It feels like an enhancement to me
because to use this feature, the user will have to use the API in a way they
haven't before, and we
Chris Jerdonek added the comment:
Note that we would also have to deal with not just the error text but also the
usage string. From the docs:
parser.parse_args('11'.split())
usage: PROG [-h] {5,6,7,8,9}
PROG: error: argument foo: invalid choice: 11 (choose from 5, 6, 7, 8, 9
New submission from Chris Jerdonek:
When passing a string for the choices argument, argparse's usage and error
messages differ from its behavior:
p = argparse.ArgumentParser()
p.add_argument('a', choices='abc')
p.parse_args(['d'])
usage: [-h] {a,b,c}
: error: argument a: invalid choice: 'd
Chris Jerdonek added the comment:
I forgot to mention that argparse uses such cases as examples in its
documentation (one of which was replaced in bddbaaf332d7).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16977
Chris Jerdonek added the comment:
argparse does not require that choices be iterable, as it *does* use 'in', as
it should. Line 2274:
if action.choices is not None and value not in action.choices:
There are cases where it's incorrect for argparse to being using in instead
Chris Jerdonek added the comment:
Also, I'm of the opinion that we'll end up with a higher quality result doing
things by hand anyway.
Automation doesn't (and shouldn't) preclude careful review and modifications by
hand. My point was that it seems like it might be able to get you, say, 80
Chris Jerdonek added the comment:
Okay, well the title of this issue is Make CPython test package discoverable,
so as part of that we should be confirming that test discovery finds the same
tests that test_main() runs (and if not, to understand why and/or make them the
same
301 - 400 of 1573 matches
Mail list logo
