Chris Jerdonek added the comment:
> The code could simply use the str or repr of the choice object
It seems to me that this would result in less user-friendly behavior in many
cases. It would also require the end-user to understand Python (e.g. xrange
and dictionaries), which I don'
New submission from Chris Jerdonek:
This issue is to upgrade Python's Sphinx from version 1.0 to 1.1.
I don't already see an issue for this, and I'm not sure what upgrading entails.
Personally, I'm interested in the enhanced indexing capabilities, e.g. the
"see"
Chris Jerdonek added the comment:
For the record, choices types implementing only __contains__ never worked in
any cases. (I should have said ArgumentParser.add_argument() raises a
ValueError in the above.)
So I wonder if we should classify this as an enhancement and simply document
the
Chris Jerdonek added the comment:
Martin, can you confirm that PyPI's behavior is as described in the patch?
--
___
Python tracker
<http://bugs.python.org/is
Chris Jerdonek added the comment:
For maintenance releases, I think I would favor abbreviating the list only if
it is "lossless" (e.g. for xrange objects). I think I would also be okay with
abbreviating for arbitrary xranges -- in particular for arbitrary steps. For
example, fo
Changes by Chris Jerdonek :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Chris Jerdonek added the comment:
Since it subclasses ImportError, it seems like we're already considering it to
be an error? StopIteration and GeneratorExit don't inherit from an "Error"
exception type unlike, say, the OSE
Chris Jerdonek added the comment:
I meant to include this link for convenience:
http://docs.python.org/dev/library/exceptions.html#exception-hierarchy
--
___
Python tracker
<http://bugs.python.org/issue15
Chris Jerdonek added the comment:
To state more explicitly the observation I alluded to in my comment above, we
currently follow (without exception -- pun intended :) ) the convention that
subclasses of exceptions that end in "Error" also end in "Error". We also do
the
New submission from Chris Jerdonek:
The code below in bytes_decode() is unnecessary:
if (encoding == NULL)
encoding = PyUnicode_GetDefaultEncoding();
(from
http://hg.python.org/cpython/file/e9af9b1ca67e/Objects/bytesobject.c#l2230 )
because PyUnicode_FromEncodedObject() already
Chris Jerdonek added the comment:
For the record, there is a test for the default encoding:
http://hg.python.org/cpython/file/e9af9b1ca67e/Lib/test/test_bytes.py#l209
--
___
Python tracker
<http://bugs.python.org/issue16
New submission from Chris Jerdonek:
Currently, the devguide does not have a table of contents. For example,
clicking the "Table of Contents" link in the left column does nothing. My
feeling is that a proper table of contents will make it easier to understand
how the devguide is or
New submission from Chris Jerdonek:
This issue is to add the "object" type to the list of types documented in the
language reference's standard type hierarchy and the library reference's list
of built-in types:
http://docs.python.org/dev/reference/datamodel.html#the-sta
Chris Jerdonek added the comment:
> The link does nothing because what is directly below the TOC link is the
> table of contents.
Yes, that's the impression one gets when the link doesn't work. But the links
below are just the sections for the current page rather than the ta
Chris Jerdonek added the comment:
Patch attached. The tests pass.
--
keywords: +patch
Added file: http://bugs.python.org/file28039/issue-16495-1-default.patch
___
Python tracker
<http://bugs.python.org/issue16
Chris Jerdonek added the comment:
Updating patch after Ezio's review on Rietveld.
--
Added file: http://bugs.python.org/file28040/issue-13538-6-default.patch
___
Python tracker
<http://bugs.python.org/is
Chris Jerdonek added the comment:
Attaching patch. Out-of-the-box at least, Sphinx seems to have the constraint
that the "home page" (what the link in the upper-left corner points to) needs
to be the same as the table of contents (what the "table of contents" link in
th
Changes by Chris Jerdonek :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Chris Jerdonek added the comment:
Attaching new patch to address Ezio's further comments (for the convenience of
comparing in Rietveld). I will be committing this.
--
Added file: http://bugs.python.org/file28045/issue-13538-7-default.
Chris Jerdonek added the comment:
Thanks, Éric! (And thanks also to Ezio who helped quite a bit with the
improvements.) I replied to your comments on Rietveld.
--
___
Python tracker
<http://bugs.python.org/issue13
Changes by Chris Jerdonek :
--
assignee: docs@python -> chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue16508>
___
___
Python-bugs-list mai
Changes by Chris Jerdonek :
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue16514>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Chris Jerdonek:
The below should probably say something along the lines of "max expected 1
positional arguments" (since the foo value is an argument):
>>> max(foo=1)
Traceback (most recent call last):
File "", line 1, in
TypeError: max e
Changes by Chris Jerdonek :
--
title: TypeError message incorrect for max() with no args -> TypeError message
incorrect for max() with one keyword arg
___
Python tracker
<http://bugs.python.org/issu
Changes by Chris Jerdonek :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Chris Jerdonek:
The null-merge instructions in the devguide (in the "note" box in the section
linked to below):
http://docs.python.org/devguide/committing.html#porting-within-a-major-version
are incomplete if the merge created conflicts. It would help
New submission from Chris Jerdonek:
This issue is to add "buffer protocol" (or perhaps "buffer object") to the
glossary. The concept is currently described here:
http://docs.python.org/dev/c-api/buffer.html#buffer-protocol
Éric initially suggested doing this in the com
New submission from Chris Jerdonek:
The TypeError message when a call to subprocess.Popen() lacks the args argument
is incorrect.
For 3.3 and 3.4, the message incorrectly says that a positional argument is
required when a keyword argument will do:
>>> import subprocess
>>>
Chris Jerdonek added the comment:
Also see the terminology-related issue 15990 created from that thread.
--
___
Python tracker
<http://bugs.python.org/issue16
Chris Jerdonek added the comment:
> Is there a bug report for this on the mercurial tracker?
Indeed there is -- by one of our own in fact :)
http://bz.selenic.com/show_bug.cgi?id=2706
--
nosy: +pitrou
___
Python tracker
<http://bugs.pyth
Chris Jerdonek added the comment:
Here is a proposed patch just to get the ball rolling on this.
Note that I'm proposing that we let ourselves use the word "standard" in place
of "positional-or-keyword" when talking about parameters. This is partly
inspir
Chris Jerdonek added the comment:
Attaching new patch incorporating David's suggestions.
--
Added file: http://bugs.python.org/file28062/issue-16517-2.patch
___
Python tracker
<http://bugs.python.org/is
Chris Jerdonek added the comment:
> TypeError: __init__() missing 1 required positional argument: 'args'
I think something like the following would be more correct:
__init__() missing argument for parameter 'args'
--
__
Chris Jerdonek added the comment:
Addressed by: http://hg.python.org/devguide/rev/78a69b929ab7
(I accidentally left the issue number out of the commit message.)
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -&g
New submission from Chris Jerdonek:
The 3.2 docs haven't updated since Oct 28, 2012:
http://docs.python.org/3.2/
The commits for the Doc folder around that time are as follows. I observed
that the top commit was not built, but I'm not sure about the ones previous:
$ hg log -b 3.2
Chris Jerdonek added the comment:
I like option (3). I attached a new patch using this approach.
As suggested, I made the glossary entries for "keyword argument" and
"positional argument" into stubs. So now there are just two substantive
entries: one for "argumen
Chris Jerdonek added the comment:
Thanks for the info. Is this information reflected somewhere online?
--
___
Python tracker
<http://bugs.python.org/issue16
Chris Jerdonek added the comment:
> The policy is that only the versions in active maintenance are automatically
> rebuilt. 3.2 is technically no longer in maintenance, it's just that there
> are reasons that we are delaying the final release.
Okay, below the devguide says
Chris Jerdonek added the comment:
It's not. Thanks for the clarification and info.
--
___
Python tracker
<http://bugs.python.org/issue16528>
___
___
Pytho
Chris Jerdonek added the comment:
I have a number of comments but it is a holiday this weekend so I might not be
able to get to it for a day or two.
--
___
Python tracker
<http://bugs.python.org/issue15
Chris Jerdonek added the comment:
+.. function:: attrgetter(attr[, attr2, attr3, ...])
Why not reword to use the *attr notation? It is even already being used below:
+ The function is equivalent to::
def attrgetter(*items):
if any(not isinstance(item, str) for item in
Chris Jerdonek added the comment:
You can also make that distinction using *. For example:
.. function:: attrgetter(attr, *attrs)
or
.. function:: attrgetter(attr)
attrgetter(attr1, attr2, *attrs)
(cf. http://docs.python.org/dev/library/functions.html#max )
Elsewhere we
Changes by Chris Jerdonek :
--
keywords: +easy
resolution: invalid -> fixed
type: behavior -> enhancement
___
Python tracker
<http://bugs.python.org/i
Changes by Chris Jerdonek :
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue16543>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
> Here we're using 'positional' to refer to parameters that PEP 362 calls
> "POSITIONAL_ONLY", whereas the regular TypeErrors (e.g. produced for
> user-defined functions) use 'positional' to mean what PEP 362 calls
Chris Jerdonek added the comment:
> This can be fixed by adding "positional" before "arguments" in the error
> message.
Do we know for sure that the values in the args argument in a call to
PyArg_UnpackTuple always correspond to the positional arguments of a call t
Chris Jerdonek added the comment:
> TypeError: f() missing 1 required positional argument: 'a'
Yes, I think this should also be changed because passing "a" as a keyword
argument is okay:
>>> f(a=1)
I would suggest something like--
TypeError: f() m
Chris Jerdonek added the comment:
> TypeError: f() missing 1 required positional argument: 'a'
By the way, changing this message is the subject of issue 16520 (which should
probably be retitled).
--
___
Python tracker
<http:/
Chris Jerdonek added the comment:
I would keep any "global" discussion (for decision and coordination purposes)
as part of a single meta-issue, but retain individual instances that need to be
corrected as separate issues. I don't think we should try to fix them all as
part
Chris Jerdonek added the comment:
Do we have a recommended (and preferably briefer) way of saying, "any object
that supports the buffer protocol"?
--
___
Python tracker
<http://bugs.python.o
Chris Jerdonek added the comment:
s/any//
--
___
Python tracker
<http://bugs.python.org/issue16518>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
> I wouldn't use "bytes-like object".
What about "buffer-like object"?
--
___
Python tracker
<ht
Chris Jerdonek added the comment:
> > That's why I'm proposing "bytes-like object".
>
> If it is somehow possible to establish the term as a shorthand for the real
meaning,
This can be established via the glossary. We can still use "buffer provider"
f
Chris Jerdonek added the comment:
> TypeError: f() missing 1 required positional argument: 'a'
The error message for round(), for example, has a different form:
>>> round()
TypeError: Required argument 'number' (pos 1) not found
It would be
Changes by Chris Jerdonek :
--
assignee: ezio.melotti ->
stage: test needed ->
title: Use "positional arguments" in PyArg_UnpackTuple -> improve TypeError
messages for missing arguments (meta issue)
___
Python tracker
<
Changes by Chris Jerdonek :
--
dependencies: +improve TypeError messages for missing arguments (meta issue)
___
Python tracker
<http://bugs.python.org/issue16
Chris Jerdonek added the comment:
I'm attaching a patch that preserves the structure of the previous patch but
that builds on the wording and formatting. The patch also addresses many of
the comments on Rietveld. I will also publish some comment replies on Rietveld
(to the previous
Chris Jerdonek added the comment:
Attaching patch.
Adding Nick to the nosy list because he did the work of originally breaking out
the "Text Sequence Type" section for issue #4966, as well as Terry who created
that issue. I view the current issue and patch as a progression of s
Chris Jerdonek added the comment:
> The simpler approach Chris has taken here (i.e. just leaving the string
> methods separate from the class definition) also works.
Yes, though I mentioned nesting the string methods beneath the class entry in
the original post for this issue, I figu
Chris Jerdonek added the comment:
Updating patch to fix up affected/related index entries.
--
Added file: http://bugs.python.org/file28124/issue-16209-2-default.patch
___
Python tracker
<http://bugs.python.org/issue16
Chris Jerdonek added the comment:
To clarify, I didn't say that _convert_names() should be used. I was just
noting that it returns a list.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Chris Jerdonek:
The docs for os.path.abspath(), os.path.basename(), and os.path.dirname():
http://docs.python.org/dev/library/os.path.html#os.path.abspath
should hyperlink to os.path.normpath() and os.path.split() as appropriate for
easier navigability
Changes by Chris Jerdonek :
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Chris Jerdonek added the comment:
The patch needs documentation, though, right?
http://docs.python.org/dev/library/argparse.html#filetype-objects
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue11
Chris Jerdonek added the comment:
On the whole, the patch looks okay to me. I think we should strive for
correctness in the documentation where possible.
While keeping "True" would keep the forward implications correct and document
the "preferred" value, there is often a
Chris Jerdonek added the comment:
Attaching new patch to address Ezio's suggestions on Rietveld. I will also
respond to those comments on Rietveld shortly.
--
Added file: http://bugs.python.org/file28142/issue-15990-5-default.patch
___
P
Chris Jerdonek added the comment:
For some reason, Rietveld is erroring out every time I try to reply to one of
the comments. So I am pasting the reply below:
[Issue in the Rietveld tracker here:
http://code.google.com/p/rietveld/issues/detail?id=394 ]
On 2012/11/26 22:07:50, ezio.melotti
Chris Jerdonek added the comment:
Attaching new patch to address Ezio's suggestions on Rietveld.
--
Added file: http://bugs.python.org/file28143/issue-16209-3-default.patch
___
Python tracker
<http://bugs.python.org/is
New submission from Chris Jerdonek:
This issue is to settle on and provide a way to document the constructor of a
class separately from the overall summary/description of a class.
This is something that Ezio, Nick, and I discussed briefly on IRC a few hours
ago. We all see the value in it
Changes by Chris Jerdonek :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Chris Jerdonek added the comment:
This was addressed by issue #16209 since with that change :class:`str` and
:func:`str` now both go to the new str class entry in the string type section.
See also the new issue #16568.
--
resolution: -> duplicate
status: open -> closed
supe
Chris Jerdonek added the comment:
I realize now that this would also be good for 2.7. I will try to do that
tomorrow.
--
versions: +Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue15
Chris Jerdonek added the comment:
Following up Andrew's last comment, for the record, it looks like this was done
as part of issue 8982.
--
nosy: +chris.jerdonek
superseder: -> argparse docs cross reference Namespace as a class but the
Namespace class is not do
Changes by Chris Kaynor :
--
nosy: +DragonFireCK
___
Python tracker
<http://bugs.python.org/issue4806>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
> Note that I took this from the pep. The pep could get the same clarification
> (unless I made it more confusing than it was).
Reading the following, it seems that PEPs aren't generally clarified after
becoming Final (as is PEP 362):
"In ge
Chris Jerdonek added the comment:
Thanks for the clarification. I will create an issue to clarify that part of
PEP 1. It should also say who is allowed to make such changes and whether/from
whom approval is necessary, etc.
--
___
Python tracker
New submission from Chris Jerdonek:
This issue is to clarify the policy in PEP 1 regarding non-substantive changes
to PEPs in the Final state (minor clarifications, rephrasings, etc).
Currently, PEP 1 says, "In general, Standards track PEPs are no longer modified
after they have reache
Chris Jerdonek added the comment:
I just created issue 16574 to clarify PEP 1 with regard to the above.
--
___
Python tracker
<http://bugs.python.org/issue15
Chris Jerdonek added the comment:
Are you saying that PEP 1 is correct and that Final PEPs should not be
modified, or that the PEP isn't correct but that it shouldn't be modified?
If the latter, for someone new it's not clear whether minor clarifications are
permitted and i
Chris Jerdonek added the comment:
Okay, so in a comment to issue 15990, Ezio suggested that some clarifying
changes to PEP 362 might be worth making. How would I (or someone else) go
about doing that? Where would they begin?
I think this recent e-mail from Nick applies:
http
Chris Jerdonek added the comment:
By the way, I don't especially care if the clarification goes in the PEP itself
or not. What's more important is that it be documented *somewhere* (which
could also be the devguide, for example). My interest in knowing the process
Chris Jerdonek added the comment:
> I think the gist here is that “in general” is good enough, given that there
> is unwritten consensus about what edits are possible in the developers’ heads.
As I said, I'm okay with keeping the PEP as is (with "in general," etc)
provid
Chris Jerdonek added the comment:
Ezio told me my previous comment was hard to understand. For the record, what
I meant was that if you have a statement like, "If *allow_nan* is ``True``,
then Otherwise, ...," then this can be read to mean that something like 1
for *allow_nan
Chris Jerdonek added the comment:
You're right. My mistake. :)
--
___
Python tracker
<http://bugs.python.org/issue4945>
___
___
Python-bugs-list m
Chris Jerdonek added the comment:
Attaching a 2.7 version of the patch for this issue.
>From the patch committed to Python 3, I removed mention of keyword-only
>parameters, inspect.Parameter, and PEP 362 (because all are specific to Python
>3).
--
Added file: http://bugs.p
Chris Jerdonek added the comment:
Thanks for the feedback. I will post here a devguide patch to include some of
this information in the devguide.
--
___
Python tracker
<http://bugs.python.org/issue16
New submission from Chris Jerdonek:
This issue is to define "PEP editor" (or "PEP editors") in PEP 1 before it is
used in the document and to provide certain clarifying information.
In particular, PEP 1 should say whether editorship is an invitation-only status
and/or h
Changes by Chris Jerdonek :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Chris Jerdonek added the comment:
Thanks for providing the info. To clarify, is membership in peps@ restricted
to editors?
--
___
Python tracker
<http://bugs.python.org/issue16
Chris Jerdonek added the comment:
>From PEP 1: "If the PEP author is a Python developer, assign the bug/patch to
>him, otherwise assign it to the [a] PEP editor."
Given that the list is small, something else that might make sense is adding a
"PEP editors" area t
Chris Jerdonek added the comment:
Btw, I will prepare a patch that incorporates the information that Barry
provided.
--
___
Python tracker
<http://bugs.python.org/issue16
Chris Jerdonek added the comment:
Attaching proposed patch.
The patch also makes some minor stylistic improvements and typo fixes (e.g.
s/work flow/workflow/, s/we/the PEP editors/, and eliminating trailing
whitespace on a few lines).
--
keywords: +patch
Added file: http
Chris Jerdonek added the comment:
> The "consisting" doesn't sound too well to me, maybe "reserved to"?
"Reserved for" sounds good to me. Originally I was thinking of "limited to" or
"restricted to," b
Chris Jerdonek added the comment:
Are there any comments on the patch from the PEP 1 authors? PEP 1 says that I
should assign this to one of the PEP authors. Any takers, or is this something
I can commit on the authors' behalf?
--
___
P
Chris Jerdonek added the comment:
David, is issue 14910 the one you were thinking of?
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue16
Changes by Chris Kaynor :
--
nosy: +DragonFireCK
versions: +Python 2.6
___
Python tracker
<http://bugs.python.org/issue16619>
___
___
Python-bugs-list mailin
Changes by Chris Rebert :
--
nosy: +cvrebert
___
Python tracker
<http://bugs.python.org/issue16619>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Chris Jerdonek :
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue16623>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
Is this issue just for 2.7? 3.3 was selected as the affected version, but the
error message text seems limited to 2.7:
http://hg.python.org/cpython/file/0adfbafe8a99/Objects/fileobject.c#l303
The exception can be reproduced simply using 2.7:
>>>
Chris Jerdonek added the comment:
> Here is a patch, which adds multiline calltips support.
Serhiy, it looks like this issue/patch is just to fix the test and not to add
"support." Also, it looks like the test only checks the first line, so that
the second line shouldn'
1901 - 2000 of 2758 matches
Mail list logo
