Chris Jerdonek added the comment:
Thanks, Jyrki and Petri. I just noticed that a "Changed in version" should
probably be added at the end of this section:
http://docs.python.org/dev/library/unittest.html#unittest.main
*defaultTest* should probably also be documented in the text (it
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
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 some
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
Changes by Chris Jerdonek :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Chris Jerdonek :
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
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
<http://bugs.py
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) be
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).
Th
Chris Jerdonek added the comment:
Looks like it's because highlightlang:: c is at the top.
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/is
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
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) instea
Changes by Chris Jerdonek :
--
nosy: +bethard, chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue17250>
___
___
Python-bugs-list mailing list
Unsub
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(des
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 w
Changes by Chris Jerdonek :
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue17227>
___
___
Python-bugs-list mailing list
Unsubscribe:
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.
Ju
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 ar
Chris Jerdonek added the comment:
Thanks, one patch should be fine, though the change should be applied to all
branches.
--
___
Python tracker
<http://bugs.python.org/issue17
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 Argu
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
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 f
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
fu
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 re
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
<http://bugs.python.org/is
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
Chris Jerdonek added the comment:
Thanks a lot for taking care of this issue, Michael.
--
___
Python tracker
<http://bugs.python.org/issue17052>
___
___
Python-bug
Chris Jerdonek added the comment:
+- Issue #17502: unittest discovery should use self.testLoader.
Also, this should read Issue #17052.
--
___
Python tracker
<http://bugs.python.org/issue17
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:
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:
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
Chris Jerdonek added the comment:
Danilo, does this work any better?
$ python setup.py sdist register -r local upload
--
___
Python tracker
<http://bugs.python.org/issue17
Chris Jerdonek added the comment:
See issue 16926 for another issue about using -r with register.
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue17
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
<http://bu
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
<http://bugs.pyt
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
<http://bugs.python.o
Chris Jerdonek added the comment:
Never mind :)
--
___
Python tracker
<http://bugs.python.org/issue17109>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Chris Jerdonek :
--
nosy: +bethard, chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue17113>
___
___
Python-bugs-list mailing list
Unsub
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 see ways that the changes can be proposed and committed incrementally. I can
start proposing those.
--
___
Python tracker
<http://bugs.python.org/issue14
Chris Jerdonek added the comment:
Also, I would be happy to start that process using the work that you have done.
--
___
Python tracker
<http://bugs.python.org/issue14
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:
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
manag
Chris Jerdonek added the comment:
See also issue 17087 which is essentially the same issue but for match objects.
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue13
Chris Jerdonek added the comment:
Is this a duplicate of issue 13592?
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue17087>
___
___
Pytho
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
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
Changes by Chris Jerdonek :
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Chris Jerdonek :
--
keywords: -easy
___
Python tracker
<http://bugs.python.org/issue16989>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 fr
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
<http://bugs.python.org/is
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
Changes by Chris Jerdonek :
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue14039>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Chris Jerdonek :
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue14037>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 t
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 scop
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 t
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 loggin
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.jerd
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,
>
>
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&#
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:
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
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:
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
<http://bugs.py
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'])
Namespac
Chris Jerdonek added the comment:
> the choice part of the error message (passed to ArgumentError) will just be
> 'invalid choice: '.
That's right. With the patch it looks like this:
>>> p = argparse.ArgumentParser(prog='test.py')
>>> p.
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
Changes by Chris Jerdonek :
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue9253>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
wh
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 sel
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
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:
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 success
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:
When choices isn't iterable but supports the "in" operator, e.g.
class MyChoices(object):
def __contains__(self, item):
return True
--
___
Python tracker
<http://bugs.pyt
Chris Jerdonek added the comment:
See issue 16468 for why that won't work in general.
--
___
Python tracker
<http://bugs.python.org/issue16977>
___
___
Pytho
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
> + metava
Chris Jerdonek added the comment:
There are also test cases with a string being passed for choices.
--
___
Python tracker
<http://bugs.python.org/issue16
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: ->
Chris Jerdonek added the comment:
I added some Rietveld comments.
--
___
Python tracker
<http://bugs.python.org/issue16970>
___
___
Python-bugs-list mailin
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
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
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/cb297930d2c
Changes by Chris Jerdonek :
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue16988>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.python.org/issue16
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 s
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 bein
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
<http://bugs.python.org/issue16
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([&#
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
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 befo
Chris Jerdonek added the comment:
I guess another option would be to mark the test CPython-only.
--
___
Python tracker
<http://bugs.python.org/issue16468>
___
___
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'
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
Chris Jerdonek added the comment:
Slight doc tweak: s/container/sequence/.
--
Added file: http://bugs.python.org/file28735/issue-16468-3.patch
___
Python tracker
<http://bugs.python.org/issue16
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(c
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
<http://bugs.pyth
Chris Jerdonek added the comment:
By the way, I think this process of using unittest (i.e. dog-fooding) is a good
exercise in part because it helps us understand better where unittest could use
improvement (e.g. the SkipTest during import issue, and the decorator issue
raised here
301 - 400 of 1575 matches
Mail list logo
