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 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:
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
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 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 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 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
Chris Jerdonek added the comment:
For completeness, I am attaching the modified version of the script that was
used to generate the latest output.
--
Added file: http://bugs.python.org/file26712/merge-acks-2.py
___
Python tracker
<h
Chris Jerdonek added the comment:
Updating patch to current tip.
--
Added file: http://bugs.python.org/file26714/issue-15543-2.patch
___
Python tracker
<http://bugs.python.org/issue15
New submission from Chris Jerdonek:
After the section describing roles that create cross-references to C-language
constructs, the Dev Guide says this, "The following roles don’t do anything
special except formatting the text in a different style."
http://hg.python.org/dev
Chris Jerdonek added the comment:
The fact that the Python implementation doesn't look at write_through doesn't
necessarily mean that it's not respected. It could always write through.
Indeed, it looks like this is the case and was discussed at one point:
http://bugs.python
Chris Jerdonek added the comment:
Attaching patch.
--
keywords: +patch
Added file: http://bugs.python.org/file26716/issue-15571-1.patch
___
Python tracker
<http://bugs.python.org/issue15
New submission from Chris Jerdonek:
The Dev Guide says not to markup True, False, and None in the documentation in
a way that generates a link (e.g. ":const:`True`") because "they’re fundamental
to the language and should be known to any programmer":
http://docs
Chris Jerdonek added the comment:
Here is a command to find the file names of all occurrences:
find Doc -type f -name *.rst | xargs grep -ERl ":const:\`(True|False|None)\`"
The occurrences are in the following directories:
Doc/c-api/
Doc/library/
Doc/reference/
Doc/whatsnew/
An
Chris Jerdonek added the comment:
Thanks for weighing in, Greg!
At least for me, this edge case was important because it determines how the
canonical advice or recipe for handling multiple paragraphs behaves when the
input string has line breaks in between paragraphs. That advice, of course
Changes by Chris Jerdonek :
--
stage: -> patch review
versions: +Python 2.7, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Chris Jerdonek added the comment:
io module experts: Can one of you review this minor change to the subprocess
documentation to make it reference the newly added io.TextIOWrapper
documentation changes?
For background purposes, digging back, it looks like the original change to
subprocess was
Chris Jerdonek added the comment:
Yes, I can see the trade off. However, is there a sense in which the situation
for documentation could be different from the situation for code?
With code, style and refactoring changes cause churn without directly
benefiting the end user (because code is
New submission from Chris Jerdonek:
Popen.communicate() raises an exception if passed no input when stdin=PIPE and
universal_newlines=True. With universal_newlines=False, no exception is
raised. For example, the following yields--
args = [sys.executable, '-c', 'pass']
Chris Jerdonek added the comment:
See issue 12623 for another issue related to communicate() and universal
newline support.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue15
New submission from Chris Jerdonek:
subprocess.Popen() with universal_newlines=True does not convert line breaks
correctly when the preferred encoding is UTF-16. For example, the following
code--
code = r"import sys; sys.stdout.buffer.write('a\r\nb'.encode('utf-16')
Chris Jerdonek added the comment:
Attaching patch for review.
--
stage: needs patch -> patch review
Added file: http://bugs.python.org/file26729/issue-15595-1.patch
___
Python tracker
<http://bugs.python.org/issu
Chris Jerdonek added the comment:
Victor, I have not personally experienced this issue. I just noticed that the
order of operations is wrong or not portable in the _translate_newlines()
method when I was looking at the code for another reason
Chris Jerdonek added the comment:
> How do you set the locale encoding to UTF-16? Do you mean UTF-16, UTF-16-LE
> or UTF-16-BE?
I confirmed that the issue occurs for all of these. For testing purposes, you
can do--
locale.getpreferredencoding = lambda do_setlocale: &
Chris Jerdonek added the comment:
Thanks for your comments.
> FYI it's not directly Popen() which uses the locale encoding, but
> TextIOWrapper.
Yes, I will note that to be more clear. Would you like me to add tests for
UTF-16-LE, etc. (via a helper test method), or will U
Chris Jerdonek added the comment:
Updating patch with Victor's comments.
--
Added file: http://bugs.python.org/file26733/issue-15595-2.patch
___
Python tracker
<http://bugs.python.org/is
Chris Jerdonek added the comment:
It looks like this also affects 3.2, but I will need to modify the test
slightly because in 3.2, TextIOWrapper calls locale.getpreferredencoding()
without any arguments.
--
versions: +Python 3.2
___
Python tracker
Chris Jerdonek added the comment:
Here is a patch also suitable for applying to Python 3.2.
--
Added file: http://bugs.python.org/file26734/issue-15595-3.patch
___
Python tracker
<http://bugs.python.org/issue15
Chris Jerdonek added the comment:
Note to reviewers: changing to "needs patch" because I want to make changes to
the latest patch before this is reviewed (e.g. to the index directives). I
should be able to do this by the end of the weekend.
--
stage: ->
Chris Jerdonek added the comment:
Nick, would you be able to take a look at this minor documentation patch re:
generators? Would you prefer this blanket statement, or an explicit (possibly
repeated) statement inside the documentation of each method?
--
versions: +Python 2.7, Python
Chris Jerdonek added the comment:
It seems like a test and documentation for this would be beneficial (for the
usual reasons, etc).
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issue15
Changes by Chris Jerdonek :
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issue11643>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
In the process of working on issue 15595, I noticed that the documentation
change will need to be slightly different for Python 3.2 than for 3.3. In 3.2,
it is locale.getpreferredencoding() (which defaults to do_setlocale=True)
instead of
Chris Jerdonek added the comment:
+If you are building the developer's guide, or for some other reason can not use
+the `tools/sphinx-build.py` file, you can also run the following command from
+the directory containing `conf.py` ::
+
+ sphinx-build -b . build/
Note that the
Chris Jerdonek added the comment:
What is the change to the documentation being suggested here? The code does
reference os.linesep, so it seems like the documentation is correct, or am I
missing something?
self._writetranslate = newline != ''
self._writenl =
Changes by Chris Jerdonek :
Added file: http://bugs.python.org/file26747/issue-15561-2-branch-32.patch
___
Python tracker
<http://bugs.python.org/issue15561>
___
___
Pytho
Chris Jerdonek added the comment:
I have uploaded updated patches for both 3.2 and the default branch. Thanks,
Andrew.
--
Added file: http://bugs.python.org/file26748/issue-15561-2-branch-default.patch
___
Python tracker
<http://bugs.python.
New submission from Chris Jerdonek:
On the core-mentorship list, Nick Coghlan suggested adding an "area" to the
Experts Index for core developers who are on the core-mentorship list (or at
least those who wish to be listed).
This issue is to do that. This can be done by adding a
Chris Jerdonek added the comment:
> I think you should better define the goal of this new section.
I see your point and may not have fully understood the intent. I'll defer to
Nick on this since the initial suggestion was his. I'm not personally wedded
to any particular reso
Chris Jerdonek added the comment:
> While working on issue 15437, it occurred to me that storing the names in a
> structured form might come in handy.
In a separate discussion, Ezio pointed out a case where we are already scraping
data about members from doc files:
http://hg.pyth
Chris Jerdonek added the comment:
- a distinct non-*NULL* pointer if possible, as if :c:func:`PyMem_Malloc(1)`
had
+ a distinct non-*NULL* pointer if possible, as if ``PyMem_Malloc(1)`` had
> From my perspective sphinx doesn't allow notations like
> :c:func:`PyMem_Malloc(1)`
Chris Jerdonek added the comment:
>
Status was still open. Was that a tracker bug?
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issu
Chris Jerdonek added the comment:
It seems like these tests can be made more DRY. For example, the line `args =
popen.cmd_line` appears in every test. You could make an assert_args() helper
method to address this. There also seems to be a lot of overlap between tests
for each browser. A
Chris Jerdonek added the comment:
> Can you reflect this fact in your patches?
Sure. (Though for stdin '\n' is converted to os.linesep and no more.)
Would you mind if I also updated the following part of the subprocess
documentation to reference the part we are updating
New submission from Chris Jerdonek:
The documentation of io.TextIOWrapper's newline argument is somewhat confusing
and perhaps reversed from what was intended. (For example, the subprocess
module uses the reverse terminology.) Either way, it can be improved somewhat.
Currently, it
Chris Jerdonek added the comment:
Andrew, I'm adding you because this is the documentation that the subprocess
module will point to after issue 15561.
--
nosy: +asvetlov
___
Python tracker
<http://bugs.python.org/is
Chris Jerdonek added the comment:
Here is an initial patch based on the core developers who responded on
core-mentorship.
In response to Ezio's comment (after thinking further), I think the goal would
be to provide a list of people that new contributors should feel welcome to add
to the
Changes by Chris Jerdonek :
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issue15626>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
I just discovered that issue 15302, which has a patch awaiting review from a
month ago as well as some discussion, is a duplicate of this issue.
Would it be possible to leave that issue open (retitling either or both issues
if necessary to avoid overlap
New submission from Chris Jerdonek:
This issue is to start running (at least some of) the doctests in the Doc/
folder's *.rst files as part of regrtest.
We will need a whitelist mechanism to tell regrtest which files to process
since currently many doctests are not runnable (e.g. some ki
Chris Jerdonek added the comment:
One option for whitelisting files would be to subclass doctest.DocTestParser
and pass an instance as the parser argument to doctest.DocFileSuite:
http://docs.python.org/dev/library/doctest.html#doctest.DocFileSuite
The custom parser could look for the per
Chris Jerdonek added the comment:
> Might it be simpler to run doctest over the rst file from the relevant
> unittest? (Perhaps with help from test.support.)
If I understand correctly, do you mean for example that
Lib/test/test_textwrap.py could be responsible for loading the docte
Chris Jerdonek added the comment:
> I'm not sure running these tests as part of regrtest is a good idea.
Can you provide reasons?
--
___
Python tracker
<http://bugs.python.org
501 - 600 of 1575 matches
Mail list logo
