Chris Jerdonek added the comment:
I don't have a problem with closing this as rejected if Victor agrees.
--
___
Python tracker
<http://bugs.python.org/is
Chris Jerdonek added the comment:
> No. Please stick to one issue at a time, and distutils2 may come back (google
> for details).
I was asking only to determine whether to create a new issue -- not to have
that issue addressed here.
> It seems to me there are missing words in the
Chris Jerdonek added the comment:
> Hmmm, in your original description you say that the 'generator.__next__'
> documentation should be changed, but in the patch the note applies to all
> generator methods.
Thanks, Meador. Yes, I realized that later. Retitling now. I
Chris Jerdonek added the comment:
The unit tests added here are another candidate for the refactoring in issue
15403 ("Refactor package creation support code into a common location"). I'll
note this in that issue.
--
nosy: +cjerdonek
___
Chris Jerdonek added the comment:
Lib/test/test_import.py also contains test code that would benefit from this
(see for example issue 15425). (Though not all files need to be refactored in
a single issue.)
--
___
Python tracker
<h
Chris Jerdonek added the comment:
The test cases uploaded to issue 7559 ("TestLoader.loadTestsFromName swallows
import errors") a while back contain a number of distinct cases (four, I think)
in which an import error can be raised. IIRC, these include a couple recursive
scenarios
Changes by Chris Jerdonek :
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issue14803>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
Ned, two questions: in the scenario you just described, is it a requirement
that your test suite's code need not be modified (even minimally) to support
coverage of subprocesses?
And can the solution assume that the test suite is spawning the P
Chris Jerdonek added the comment:
I understand that. Sorry, I meant to say "code under test."
If you make no assumptions about spawning subprocesses, does this mean, for
example, that the solution must satisfy the case of subprocesses invoking a
different version of Python, or in
Chris Jerdonek added the comment:
I feel like it is already too large (it is over 1750 lines), and I did not want
to create a third sibling test support module (there is also
test/script_helper.py that overlaps with test.support). Do you think that the
community would be open to refactoring
Chris Jerdonek added the comment:
At this point, would you advise me to add even more to the existing hodge
podge, or to create a third sibling test support module? My patch adds closely
related test support functionality.
Incidentally, this discussion relates to the point I was getting at
Chris Jerdonek added the comment:
Okay, then in the interest of understanding why various alternatives fail, I'll
just throw out the suggestion or question that I had in mind because I don't
see it mentioned above or on the web page.
Why wouldn't it work to define an alias
Chris Jerdonek added the comment:
Thanks for your thoughts. For the purposes of this patch, I will change to
putting the new support functionality in test.support. Going forward, if we
could do some of the refactoring for 3.3.1, that would be great. :)
I worry that the third option may make
Chris Jerdonek added the comment:
> Less favorable, because it produces longer import strings
("test.support.some_helper" instead of "test.some_helper").
This can be addressed by exposing the API in __init__.py though (as does, say,
th
Chris Jerdonek added the comment:
In working on the patch for this issue, I also noticed that there is a minor
error in the documentation of the replace_whitespace attribute.
The docs say that string.whitespace is used, but the code uses a hard-coded
string and includes a comment explaining
New submission from Chris Jerdonek:
I'm not sure if I'm filing this in the right place since I don't see
hg.python.org in the tracker "components" list, but if one clicks on the
"Browse online" link of the Dev Guide here:
http://docs.python.org
Chris Jerdonek added the comment:
Sorry, that link should have been--
http://hg.python.org/cpython/file/1d811e1097ed/Lib/textwrap.py#l12
(hg.python.org seems to default to the 2.7 branch. I just filed an issue about
this.)
--
___
Python tracker
New submission from Chris Jerdonek:
While working on issue 1859, I noticed that textwrap.wrap()'s tab expansion
does not seem to behave sensibly.
In particular, the documentation says, "If expand_tabs is true, then all tab
characters in text will be expanded to zero or more spaces,
Chris Jerdonek added the comment:
If people are interested, I filed a new issue (issue 15492) about textwrap's
tab expansion that I noticed while working on this issue.
--
___
Python tracker
<http://bugs.python.org/i
Chris Jerdonek added the comment:
> > (3) the branch name should be diplayed somewhere on the page when
> > browsing (or better yet, also in the URL itself).
>
> This seems to be a bug in hgweb, and you should report it upstream.
I filed an issue for this upstream as yo
New submission from Chris Jerdonek:
This issue is to move test/support.py into a test.support subpackage as
discussed in issue 15403.
This can be done post-release.
--
components: Tests
messages: 166848
nosy: cjerdonek, ncoghlan, pitrou
priority: normal
severity: normal
status: open
Chris Jerdonek added the comment:
Sounds good. Later today I will create an issue to move test/support.py into a
test.support subpackage post-release.
We can continue the discussion of how to organize it there.
--
___
Python tracker
<h
Chris Jerdonek added the comment:
If people are okay with populating test/support/__init__.py with code (at least
initially), the first patch could be to move support.py into
test/support/__init__.py. One nice thing about this approach is that the
calling code won't need to change.
Chris Jerdonek added the comment:
> Later today I will create an issue to move test/support.py into a
> test.support subpackage post-release.
I created issue 15494 for this.
--
___
Python tracker
<http://bugs.python.org/i
Changes by Chris Calloway :
--
nosy: +cbc
___
Python tracker
<http://bugs.python.org/issue15454>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Chris Jerdonek:
This issue is to correct the list of whitespace characters to replace in the
documentation for the textwrap module's TextWrapper.replace_whitespace
attribute.
The documentation says this list is string.whitespace:
http://docs.python.org/dev/li
Chris Pickett added the comment:
Thanks everyone!
--
___
Python tracker
<http://bugs.python.org/issue15232>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
Shouldn't a test be added to check that the issue has been fixed though (i.e. a
test with a path longer than the original 100 characters)?
I provided a patch to show how this can easily be done.
I would be happy to write the
Chris Jerdonek added the comment:
> I didn't want to write such test, but I can review a patch adding such test.
Thank you. I will provide a patch for your review.
I think a test for the path may be better as that was the original issue
exp
Chris Jerdonek added the comment:
Attaching patch with test case for long script path.
This test failed on my system before the fix and passes after.
--
Added file: http://bugs.python.org/file26601/issue-15463-2.patch
___
Python tracker
<h
Chris Jerdonek added the comment:
Is it okay for me to reopen this issue to review the patch to add a test case
for file paths longer than 100 characters, or should I create a new issue for
that?
--
___
Python tracker
<http://bugs.python.
Chris Jerdonek added the comment:
Meador, does this language look okay to you now that it states the exception
type?
--
___
Python tracker
<http://bugs.python.org/issue15
New submission from Chris Jerdonek:
While working on issue 1859, I found that textwrap.wrap() returns an empty list
when passed the empty string:
>>> from textwrap import wrap
>>> wrap('')
[]
as opposed to a list containing the empty string which is what I ex
Chris Jerdonek added the comment:
Marking issue 15510 as a dependency because there is a behavioral issue in
existing use cases that affects how to proceed in this issue.
--
dependencies: +textwrap.wrap('') returns empty list
___
Pyth
Chris Jerdonek added the comment:
Since Martin is busy, is there anything I can do to help close this very minor
change? It seems to be in a half-committed state right now.
--
___
Python tracker
<http://bugs.python.org/issue15
Chris Jerdonek added the comment:
Thanks, Eli. I know Éric had marked in the tracker for the change to be done
in 2.7 and 3.2 as well.
--
___
Python tracker
<http://bugs.python.org/issue15
Chris Jerdonek added the comment:
I haven't commented on the content of your patch (I'm not knowledgeable enough
in this area), but as for your test, I noticed that you removed the part that
asserted something about the argument passed to cb().
Ideally when testing a callback, y
Chris Jerdonek added the comment:
> However, the -C option doesn't cover the case of *implicit* invocation of
> subprocesses. This is where the PYTHONRUNFIRST suggestion comes in
Would a more general solution than PYTHONRUNFIRST be something like a suitably
named PYTHONRUNINSTEAD?
Chris Jerdonek added the comment:
> Could you possibly write a patch for 2.7, 3.2 and 3.3?. With a test :-)
I would be happy to write a patch with tests (I think there may be a few edge
cases we would want to test here). Should be ready within the next one or two
d
Chris Calloway added the comment:
At the PyOhio sprints, I noticed this issue and found it interesting for low
hanging fruit. First I went to make tests for this enhancement, only to find
that report(), report_partial_closure(), and report_full_closure did not
already have tests.
In adding
Chris Jerdonek added the comment:
> Should adding tests for the report methods be a separate issue from this
> enhancement?
Yes, I would create separate issues for this. I would even recommend
separating this into one issue for the report() methods (could be done first),
and another
Changes by Chris Jerdonek :
--
nosy: +cbc
___
Python tracker
<http://bugs.python.org/issue15450>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Chris Rebert :
--
nosy: +cvrebert
___
Python tracker
<http://bugs.python.org/issue12370>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
Attaching patch with test cases.
I added 6 new tests:
*test_empty_string
test_whitespace_trailing
*test_drop_whitespace__all_whitespace
*test_initial_indent__empty_string
test_subsequent_indent__trailing_whitespace
test_subsequent_indent__long_indent
The
Chris Jerdonek added the comment:
Actually, here is a slightly more benign version of the patch.
This patch makes the change in the wrap() method and leaves _wrap_chunks()
alone.
This is less intrusive because it doesn't change the behavior of
_wrap_chunks(), which some people mig
New submission from Chris Calloway:
The filecmp module has no tests for the following methods of the dircmp class:
report()
report_partial_closure()
report_full_closure()
The attached patch provides those tests. This issue was suggested in issue
15454. Future plans for these tests are
Changes by Chris Calloway :
--
nosy: +cjerdonek
type: -> enhancement
___
Python tracker
<http://bugs.python.org/issue15518>
___
___
Python-bugs-list mai
Chris Calloway added the comment:
Thank you and the issue to add report method tests is issue 15518.
--
___
Python tracker
<http://bugs.python.org/issue15
Chris Jerdonek added the comment:
Thanks, Chris. A couple high-level comments.
I know this isn't the prevailing style of the existing tests, but it's
generally better if each unit test tests just one thing. That way, for
example, if a test fails you know more precisely what is n
Chris Calloway added the comment:
> Would it be possible to structure things so that you have tests like
> test_report(), test_report_partial_closure(), etc?
Yes, I would prefer that structure. I was just being consistent, as you said,
with the prevailing style of the existing tests.
Chris Jerdonek added the comment:
> The tempfile-generated directory names are part of the report method output
> and are not known in advance.
There are at least two ways you could deal with this. You could change the
working directory to the temp directory in setUp() and change it b
New submission from Chris Jerdonek:
The Dev Guide should say the preferred way (or even a way) to run tests using
the Python 2.7 build:
http://docs.python.org/devguide/runtests.html
This will help submitters who want to check that their patch works with 2.7.
In Python 2.7, this did not work
Chris Jerdonek added the comment:
I verified that this patch can be applied to 2.7 and that those tests pass as
well.
--
___
Python tracker
<http://bugs.python.org/issue15
Chris Jerdonek added the comment:
> FWIW this is already mentioned in the quick start [0].
I didn't catch that, thanks.
> Do you want to propose a patch for runtest.rst?
Sure.
--
___
Python tracker
<http://bugs.python.
Chris Jerdonek added the comment:
Attaching a patch for review.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file26645/issue-15521-1.patch
___
Python tracker
<http://bugs.python.org/issu
Chris Jerdonek added the comment:
> Please backport and leave open for distutils2.
Éric, is there a place where updates to the distutils2 docs can be viewed and
made prior to reinclusion in the main Python repo? For example, the
documentation here:
http://packages.python.org/Distuti
Chris Jerdonek added the comment:
> I didn't want to write such test, but I can review a patch adding such test.
Victor, did you see and review my patch? There is currently no test to check
that a long file path (longer than 100 characters) will render, which was the
original issue
Chris Jerdonek added the comment:
> Yes, I saw your patch, but I don't want to create very long filename.
Not all platforms support paths longer than 500 characters.
I think you may have a slight misunderstanding. My patch was not meant to test
paths over 500 characters. It test
Chris Jerdonek added the comment:
Here are additional test cases impacted by this issue:
>>> wrap(" ")
[]
>>> wrap("\n\n\n")
[]
>>> wrap("\n\n\n", replace_whitespace=False)
[]
>>> wrap(" \n\n", replace_whitespace=F
Chris Calloway added the comment:
> There are at least two ways you could deal with this. You could change the
> working directory to the temp directory in setUp() and change it back in
> tearDown(). This is a common pattern in the tests [...]
> Alternatively, you could s
Chris Jerdonek added the comment:
> However, I would like your blessing to continue with assertRegex in this case.
Sure, you can proceed that way. :) My suggestions were just that --
suggestions for you to consider. And I am not a core developer, so my approval
won't necessarily
Chris Jerdonek added the comment:
It is a relatively large section (nine paragraphs + six code snippets) and is
primarily about the in-development branch, so I did not want to interrupt the
flow with a remark specific to 2.7. I also liked that the instructions in a
subsection could be linked
Changes by Chris Jerdonek :
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issue15526>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Chris Jerdonek :
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issue15496>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Chris Jerdonek :
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issue7443>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Chris Jerdonek:
The sentence describing Popen()'s cwd argument in the subprocess documentation
seems reversed to me:
http://docs.python.org/dev/library/subprocess.html#subprocess.Popen
It says, "If cwd is not None, the child’s current directory will be chang
Chris Jerdonek added the comment:
Has this issue been resolved? I saw that the following change is on the web
site today:
http://hg.python.org/devguide/rev/851adff2d434
(though I didn't verify it immediately, just 6 hours after).
--
___
P
Chris Jerdonek added the comment:
I also think this would be worth a note. May I propose a patch?
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issue14
Chris Calloway added the comment:
Well, really, the reason I'm deferring is to get the patch accepted, because it
seems kind of unacceptable for standard library modules not to have full test
coverage. So far, I don't see evidence that the issue has even been triaged. Of
the three
Chris Jerdonek added the comment:
> Of the three approaches, regex, cd, or decoration, which do you see as most
> likely to be accepted?
In my limited experience, I think the patch most likely to be accepted is the
one that changes existing code the least. That would mean adding
Chris Jerdonek added the comment:
I am attaching a proposed patch for this issue.
I also did not know whether the errors were normal when building with Windows
for the first time.
--
Added file: http://bugs.python.org/file2/issue-14873-1.patch
Chris Jerdonek added the comment:
Attaching proposed wording along the lines Martin suggested.
--
keywords: +patch
Added file: http://bugs.python.org/file26667/issue-15311-2.patch
___
Python tracker
<http://bugs.python.org/issue15
Chris Jerdonek added the comment:
Attaching an updated patch. Changes include:
1. Cleans up and expands support API to include creating nested directory
structures (for use in the filecmp tests, for example).
2. Adds unit tests for the full API (similar to test_support.py).
3. Refactors
Chris Jerdonek added the comment:
Whether or not the current language is technically correct, I would support
improving its clarity.
Would you like to create a formal patch? Also, note that the newest
documentation is published here:
http://docs.python.org/dev/reference/datamodel.html
New submission from Chris Jerdonek:
"Universal newlines" of PEP 278 does not seem to have a central, linkable
description within the documentation. In particular, there does not seem to be
a glossary entry or any index entries for it.
The main documentation seems to be in the mid
Changes by Chris Jerdonek :
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issue15204>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
Since universal newline mode is discouraged and getting deprecated in the
built-in open() function, the "central" place for describing universal newlines
should probably not be the documentation for the open() method. I am leaning
towards a glos
Chris Jerdonek added the comment:
> That's because wrap() suppresses extra whitespace by default.
But the documentation for drop_whitespace clearly states that, after wrapping,
"leading whitespace in the first line is always preserved, though."
> Once extra whitespace i
Chris Jerdonek added the comment:
See also: f17a1410ebe5
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue15543>
___
___
Python-bugs-list mailin
Chris Jerdonek added the comment:
> There may (or may not :-)) be a misunderstanding. Universal newlines are not
> discouraged; it's the legacy "U" flag which is deprecated.
Already understood. :) (I said "in the built-in open() function" above and
meant &quo
Chris Jerdonek added the comment:
> After discussing issue15510, I think this should probably be left as-is, or
> be implemented in a separate function so as to avoid breaking compatibility.
Note that this issue can be addressed without affecting backwards compatibility
in the docu
Chris Jerdonek added the comment:
> > wrapping, "leading whitespace in the first line is always preserved,
> > though."
> Ok, then it's a bit fuzzy. That whitespace is as much trailing as
> leading, after all :)
That's why the word "always"
Chris Jerdonek added the comment:
> As far as these changes don't fix obvious bugs, no, they shouldn't.
People certainly rely on the current behaviour, and they will start
getting extraneous newlines if you change it (because they will call
'\n'.join(...)).
That line of
Chris Jerdonek added the comment:
> Ok, I probably read the issue too quickly. Feel free to ignore my
> comment then :-)
Thanks. I will prepare another patch for this issue with documentation and
test cases of existing behavior. The discussion can of course continue if
anyone would l
Chris Jerdonek added the comment:
> On the other hand, the details of the *newline* argument should probably
> remain in the API descriptions themselves.
Correct. It would be a high-level entry for "universal newlines" --
independent of any API and suitable for linking to wh
New submission from Chris Jerdonek:
The documentation for str.splitlines()--
http://docs.python.org/dev/library/stdtypes.html#str.splitlines
includes a statement that is not quite correct:
"Unlike split(), if the string ends with line boundary characters the returned
list does not ha
Changes by Chris Jerdonek :
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issue15556>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
> There already is a hook in place for the main python.org repository that
> checks for and rejects changesets that include files with space issues:
If there is already a hook, then why do some files have spurious white space
(i.e. at the end of a line
Chris Jerdonek added the comment:
I didn't have a chance to respond before you closed this issue. I will add
more information later if that is okay. :)
--
___
Python tracker
<http://bugs.python.org/is
Chris Jerdonek added the comment:
> I wasn't really happy with the addition of that sentence about split in the
> first place.
I think the instinct to put that sentence in there is a good one. It is a key,
perhaps subtle difference.
> I don't understand what your spli
Chris Jerdonek added the comment:
Attaching patch with simplified wording in response to R. David Murray's
feedback.
In particular, "a terminal line break does not delimit an additional empty
line" -> "a terminal line break does not result in an extra line."
New submission from Chris Jerdonek:
This is an issue to update the subprocess module documentation after updates to
io.TextIOWrapper's documentation here:
http://hg.python.org/cpython/rev/f17a1410ebe5
This issue was discussed briefly on python-dev:
http://mail.python.org/pipermail/p
Chris Jerdonek added the comment:
Yes, the documentation for str.casefold() suggests that lower() is not meant to
casefold:
"For example, the German lowercase letter 'ß' is equivalent to "ss". Since it
is already lowercase, lower() would do nothing to 'ß&#x
Chris Jerdonek added the comment:
Attaching a patch for review.
--
keywords: +patch
stage: -> patch review
Added file: http://bugs.python.org/file26706/issue-15543-1.patch
___
Python tracker
<http://bugs.python.org/issu
Chris Jerdonek added the comment:
Out of curiosity, is there a mechanism to bypass the hook on a per-file basis,
if necessary? FWIW, the WebKit open source project had a similar hook (for
SVN) to prevent the inclusion of tabs in source files, and a custom SVN
property was used to bypass the
Chris Jerdonek added the comment:
> in the patch it now sounds like you are saying that ''.splitlines() does not
> return the same result as ''.split() when in fact it does.
The two differences occur only when split() is passed a separator. split()
uses a d
Chris Jerdonek added the comment:
> I think the problem really is that 'split' has such radically different
> behavior when given an argument as opposed to when it isn't.
Yep, the split() documentation is much more involved because of that.
> Please move the keeplines
Chris Jerdonek added the comment:
Here you go. Thanks again.
--
Added file: http://bugs.python.org/file26709/issue-15554-4.patch
___
Python tracker
<http://bugs.python.org/issue15
Chris Jerdonek added the comment:
Victor, would you be able to take a look at this minor documentation patch? It
incorporates the change that you suggested we make on python-dev.
--
___
Python tracker
<http://bugs.python.org/issue15
Chris Jerdonek added the comment:
Is this issue awaiting feedback from anyone else before it can proceed further?
(Just this issue and not issue 15439 to make any adjustments to the docs.)
I am attaching an updated diff after generating the script output again against
the tip (modified to
1101 - 1200 of 2758 matches
Mail list logo
