Chris Jerdonek added the comment:
Attaching updated patch that clarifies the accepted non-numeric types as Serhiy
suggested on Rietveld.
I also made a few other changes like linking to integer literal and updating
the base-radix reference. As I began to suspect, the latter was left over
Chris Jerdonek added the comment:
To simplify and keep the discussions more focused, etc, I would create a new
issue for the patch to patchcheck (and mark it enhancement). Both issues can
still reference each other.
--
___
Python tracker rep
New submission from Chris Jerdonek:
Date: Tue, 11 Sep 2012 16:20:54 +0200
To: d...@python.org
Subject: [docs] packaging documentation should be removed
docs.python.org/dev still carries documentation for packaging, despite the
package
having been removed. http://docs.python.org/dev/library
New submission from Chris Jerdonek:
Date: Thu, 13 Sep 2012 00:28:20 -0700
To: d...@python.org
Subject: [docs] Bug in documentation for mailbox module
I think I may have found a minor bug in the documentation for the
mailbox module, at:
http://docs.python.org/library/mailbox.html
Right
New submission from Chris Jerdonek:
Date: Thu, 13 Sep 2012 09:42:47 -0400
To: d...@python.org
Subject: [docs] Problem with the documentation for string.replace
From http://docs.python.org/library/string.html
string.replace(str, old, new[,
maxreplace])?http://docs.python.org/library
New submission from Chris Jerdonek:
Date: Thu, 20 Sep 2012 15:14:36 -0400
To: d...@python.org
Subject: [docs] map objects are not lists
5.1.3. List
Comprehensionshttp://docs.python.org/dev/tutorial/datastructures.html#list-comprehensions
List comprehensions provide a concise way
Chris Jerdonek added the comment:
Good improvement. LGTM.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16036
___
___
Python-bugs-list mailing
New submission from Chris Jerdonek:
The following error text is incorrect in at least one way:
int(base=1000, x='1')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: int() arg 2 must be = 2 and = 36
The *base* argument can also be 0. Secondly, the text should
Chris Jerdonek added the comment:
Locations:
Objects/longobject.c
1994:int() arg 2 must be = 2 and = 36);
4273:int() arg 2 must be = 2 and = 36);
--
___
Python tracker rep...@bugs.python.org
http
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16056
___
___
Python
Chris Jerdonek added the comment:
Thanks a lot for the report. Does the 2.7 branch have similar instances?
--
nosy: +ezio.melotti, michael.foord, pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16056
Chris Jerdonek added the comment:
Ezio, do you want to commit this or should I?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16036
New submission from Chris Jerdonek:
This issue is to simplify the documentation of the built-in function int()'s
signature:
int([number | string[, base]])
and to make any needed changes to the text of the docs as a consequence.
Discussion around this issue began in the comments to issue
Chris Jerdonek added the comment:
To make it easier to make progress on this docstring issue, I created issue
16036 to focus on int()'s reST documentation. (I have a comment on that
aspect.) This will allow the current issue to focus on the docstring aspect.
--
nosy: +chris.jerdonek
Chris Jerdonek added the comment:
Fixed, and thanks for the report!
(Ezio, I didn't add code-block:: sh because it resulted in some undesired
highlighting in the interpreter portion when I tried it.)
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
Chris Jerdonek added the comment:
[Continuing the issue 14783 discussion]
That said, I don't have a strong opinion about this, so if people think that
x should be used, it's fine with me.
I also feel that *x* should be used, since that is what the code enforces.
I'm attaching a revised
Chris Jerdonek added the comment:
- :meth:`close`\ d without adding any files to the archive, the appropriate
+ :meth:`close close`\ d without adding any files to the archive, the
appropriate
This formatting looks odd to me when rendered (both cases). I would perhaps
suggest something
New submission from Chris Jerdonek:
The built-in function int() does not seem to have any basic unit tests (e.g. in
test_builtin). It would be good to add some.
Some cases (including edge cases) for possible inclusion:
int()
int(base='foo') # no exception; returns 0
int(x=5)
int(x=5, base
Chris Jerdonek added the comment:
Thanks for the pointer. That should do it. :) Searching for test_int(
completely missed test_int.py.
--
resolution: - invalid
stage: - committed/rejected
status: open - closed
___
Python tracker rep
Chris Jerdonek added the comment:
[Reopening] Actually, there may still be value in this. Not all of the edge
cases I mentioned are covered (e.g. calling using keyword arguments).
--
resolution: invalid -
stage: committed/rejected - test needed
status: closed - open
title: create
Chris Jerdonek added the comment:
We should also add a code-comment pointer in test_builtin to test_int (where
test_int() would be located).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16045
Chris Jerdonek added the comment:
Good thought. Here is one data point:
$ pypy
Python 2.7.2 (341e1e3821fff77db3bb5cdb7a4851626298c44e, Jun 09 2012, 14:24:11)
[PyPy 1.9.0] on darwin
Type help, copyright, credits or license for more information.
int()
0
int(x='10', base=8)
8
int(x=5, base=10
Chris Jerdonek added the comment:
I'm attaching an updated patch that does not cover certain edge cases that may
differ for other Python implementations (and in fact does differ for PyPY).
See issue 16045 for more information.
--
Added file: http://bugs.python.org/file27307/issue
Chris Jerdonek added the comment:
Thanks for the report. Minor clarification for future reference. Subsequent
lines should begin with ... (when doctest-style is used):
def breadth_first_search(unsearched):
... node = unsearched.popleft()
etc.
--
nosy: +chris.jerdonek
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7897
___
___
Python
Chris Jerdonek added the comment:
I don't mind fixing the year suggestion (in the interest of realism and for
practice).
--
nosy: +chris.jerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16015
Chris Jerdonek added the comment:
We should be able to add the make touch target to the 2.7 Makefile without
running afoul of the no new features rule.
To keep things simpler, I'm going to create a separate issue for this so that
it can be discussed and committed independently of this doc
New submission from Chris Jerdonek:
This issue is to add make touch to the 2.7 Makefile as suggested by Nick
Coghlan in the following comment to issue 15964:
We should be able to add the make touch target to the 2.7 Makefile without
running afoul of the no new features rule.
(from http
Chris Jerdonek added the comment:
We should be able to add the make touch target to the 2.7 Makefile without
running afoul of the no new features rule.
I created issue 16004 for this: http://bugs.python.org/issue16004
--
___
Python tracker rep
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
keywords: +needs review
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15964
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +cjerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15034
___
___
Python-bugs
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +cjerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13440
___
___
Python-bugs
Chris Jerdonek added the comment:
If this is true, we could simply add a way to specify the branch (either a
dropdown in the roundup UI or an X.Y in the filename).
It would be cool if this could happen even without any user action (e.g. if
Rietveld tried default, 3.2, and 2.7 in sequence
Chris Jerdonek added the comment:
So can you find out why asdl_c.py actually printed this error?
I collected some additional information. Here is the beginning of
Parser/asdl_c.py:
#! /usr/bin/env python
Generate C code from an ASDL description.
And in the scenario of this issue I have
Chris Jerdonek added the comment:
Some minor comments:
-The operators , , ``==``, ``=``, ``=``, and ``!=`` compare the
+, , ``==``, ``=``, ``=``, and ``!=`` compare the values of two
I think it reads better to start a sentence (and in this case a paragraph) with
a word rather
Chris Jerdonek added the comment:
In the future, now that a few more people know, we could always look to see
what doc changes were made since the last publication of the docs (or run the
other `make` commands locally, or ideally, beforehand in cases that warrant
it). The fact that 2.7
Chris Jerdonek added the comment:
Attaching patch.
I started a new section in the FAQ called Build Troubleshooting which is
something Nick suggested in the context of addressing this issue. I'm sure we
could add a couple more questions to this section right now if we wanted
Chris Jerdonek added the comment:
Adding Nick because he is the one that suggested adding a Build
Troubleshooting section to the devguide FAQ (meant to add him above).
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http
Chris Jerdonek added the comment:
The distinction between ? vs. � for encode() and decode() is in the Python
docs, but it's not prominent. It's mentioned in codecs's Codec Base Classes
but not in the encode() and decode() docs themselves:
http://docs.python.org/dev/library/codecs.html#codec
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15952
___
___
Python-bugs
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15951
___
___
Python-bugs
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15935
___
___
Python-bugs
Chris Jerdonek added the comment:
I have a brief documentation patch in mind for this, but it relies on
documentation issue 15952 being addressed first (e.g. to say that format(value)
returns Unicode when format_spec is Unicode and that value.__format__() can
return a string of type str). So
Chris Jerdonek added the comment:
Thanks for taking a look at this, and good question.
Without restructuring how the tests are done, I believe the short answer is no.
The funny thing about this test module is that it does not actually have any
unittest test cases. It just calls some
Chris Jerdonek added the comment:
Thanks, Ezio!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15304
___
___
Python-bugs-list mailing list
Chris Jerdonek added the comment:
We could start by establishing the argument/parameter distinction in the
glossary. Currently, the word parameter does not appear in the glossary, and
the definition of argument blurs the distinction between the two:
For example, in the following definition
Chris Jerdonek added the comment:
IMHO as soon as you use terms like receives or accepts, you are still
talking about arguments.
Even PEP 362 is loose with its language in this regard. For example, at the
beginning of the Signature Object section:
For each parameter accepted
Chris Jerdonek added the comment:
The 2.7 docs seem not to be affected by this issue (they are current) -- just
the docs for 3.2 and the default branch.
--
versions: +Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http
New submission from Chris Jerdonek:
This issue is to switch test_curses to using unittest.TestCase classes.
Currently, test_curses does not use unittest.TestCase. It just calls a series
of functions that exercise curses functionality and aborts if an exception
occurs:
http://hg.python.org
Chris Jerdonek added the comment:
FYI, I created issue 16000 :) to switch test_curses to using unittest.TestCase.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15852
Chris Jerdonek added the comment:
Switching this to a devguide issue so the work-around can be documented, for
example in this section:
http://docs.python.org/devguide/faq.html#how-do-i-switch-between-branches-inside-my-working-copy
--
assignee: - docs@python
components: +Devguide
Chris Jerdonek added the comment:
Sure, I could start work on such a patch. I may start by switching just a
couple of the functions to TestCase though (to establish a model and to make
sure everything is wired up correctly), rather than attempting to switch the
entire module all at once
Chris Jerdonek added the comment:
Here is an initial patch for discussion. As I started to say in my previous
comment, I think it would be worth settling on the wiring (e.g.
setUp/tearDown/etc) before trying to do more.
Some comments on the current patch:
(1) Of the following methods, it's
New submission from Chris Jerdonek:
The documentation for round() says:
round(x[, n])
Return the floating point value x rounded to n digits after the decimal point.
If n is omitted, it defaults to zero. Delegates to x.__round__(n).
(from http://docs.python.org/dev/library/functions.html#round
Chris Jerdonek added the comment:
Here is a patch. Also, I checked, and there is already a test for the keyword
arguments:
http://hg.python.org/cpython/file/dcced3bd22fe/Lib/test/test_builtin.py#l1239
--
keywords: +needs review, patch
stage: needs patch - patch review
Added file
New submission from Chris Jerdonek:
There is currently some ambiguity in our documentation around positional and
keyword arguments (e.g. whether positional means position-only or
non-keyword (roughly) and whether various terms and definitions should be for
the calling syntax or the function
Chris Jerdonek added the comment:
Thanks for the quick commit, Mark. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15985
___
___
Python-bugs
Chris Jerdonek added the comment:
Personally I think the best solution is to have the test framework allocate a
single test directory
This is partially done. See here:
http://hg.python.org/cpython/file/19c74cadea95/Lib/test/regrtest.py#l1810
# Run the tests in a context manager
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +cjerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6471
___
___
Python-bugs
Chris Jerdonek added the comment:
The case that python is a Python 3 binary is not a supported installation
Just to clarify, in the original scenario, python did not refer to anything.
From the original comment:
$ python
No such file or directory
(python2 and python3 did refer
Chris Jerdonek added the comment:
Yes, that works. Rather than closing this as won't fix, however, I would
suggest that we document the workaround in the devguide.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15964
Chris Jerdonek added the comment:
It has been 8 days since the last update.
--
priority: normal - high
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15949
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +cjerdonek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10967
___
___
Python-bugs
Chris Jerdonek added the comment:
One important piece is that regrtest currently has no tests (e.g. there is no
test_regrtest.py), so changing it must be done more carefully. How do people
feel about new (or newly modified) regrtest classes and functions going into a
different fully-tested
Chris Jerdonek added the comment:
Attaching an updated patch that does not render the import statements in the
final HTML, so that it renders the same as before.
--
Added file: http://bugs.python.org/file27227/issue-15888-2.patch
___
Python tracker
Chris Jerdonek added the comment:
If we don't fix this (I'm leaning that way myself), I think we should somehow
document the limitation. There are ways to acknowledge the limitation without
getting into the specifics of this particular issue
Chris Jerdonek added the comment:
Thanks, Ezio!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14873
___
___
Python-bugs-list mailing list
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15939
___
___
Python-bugs
Chris Jerdonek added the comment:
My opinion on the +LINUX and +WINDOWS doctest directives in
Doc/library/ctypes.rst is simply to leave them alone for now. We can make
those errors go away in code when running doctest by adding no-op calls to
doctest.register_optionflag() as below
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +loewis, ned.deily
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15949
___
___
Python
New submission from Chris Jerdonek:
Building with--
./configure --with-pydebug make -j2
errors out after switching branches from default to 2.7 when the system Python
is Python 3 (on Mac OS X 10.7.4 using MacPorts).
To reproduce:
$ sudo port select python python32
$ python
No such file
Chris Jerdonek added the comment:
Here is a proposed patch.
One note on the patch. I feel the second sentence of the note is worth adding
because value.__format__() departs from what PEP 3101 says:
Note for Python 2.x: The 'format_spec' argument will be either
a string object or a unicode
Chris Jerdonek added the comment:
To clarify, one of the sentences above should have read, I feel the second
sentence of the note *in the patch* was worth adding... (not the second
sentence of the PEP note I quoted).
--
___
Python tracker rep
Chris Jerdonek added the comment:
To follow up on David's comment, the unit tests in the test suite aren't
consistent in their treatment of temp directories (e.g. they don't use a common
API or code path). So it may be hard to address this globally short of wiping
the entire temp directory
Chris Jerdonek added the comment:
What about patch_object()?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11664
___
___
Python-bugs-list
Chris Jerdonek added the comment:
Attached is a proposed patch.
Some explanation behind the patch that stems from the above comments:
The following is an example of Formatter.format() returning str in the current
implementation that would break if we made Formatter.format() return unicode
Chris Jerdonek added the comment:
Eric, it looks like you wrote this comment:
/* don't define FORMAT_LONG, FORMAT_FLOAT, and FORMAT_COMPLEX, since
we can live with only the string versions of those. The builtin
format() will convert them to unicode. */
in http://hg.python.org/cpython
Chris Jerdonek added the comment:
See this code comment:
/* don't define FORMAT_LONG, FORMAT_FLOAT, and FORMAT_COMPLEX, since
we can live with only the string versions of those. The builtin
format() will convert them to unicode. */
from http://hg.python.org/cpython/file/19601d451d4c
Chris Jerdonek added the comment:
Adding failing test. Patch coming next.
--
keywords: +patch
nosy: +cjerdonek
stage: - needs patch
Added file: http://bugs.python.org/file27204/issue-15951-test-1.patch
___
Python tracker rep...@bugs.python.org
http
Chris Jerdonek added the comment:
Here are some related failing cases that I found:
f = string.Formatter()
f.format(u{0}, )
''
f.format(u{0}, 1)
'1'
f.format(u{0}, a)
'a'
f.format(u{0}{1}, a, b)
'ab'
f.format({0}, ua)
u'a'
Note that PEP 3101 says the following:
In all cases, the type
Chris Jerdonek added the comment:
Actually, I'm going to defer on creating a patch because this covers more
scenarios than I originally thought and so may require more time.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Chris Jerdonek added the comment:
What about cases like this?
f.format(u'{0}', '\xe9')
'\xe9'
It seems fixing this issue for non-empty strings would cause formerly running
cases like this to raise UnicodeDecodeError.
unicode('\xe9')
...
UnicodeDecodeError: 'ascii' codec can't decode byte
Chris Jerdonek added the comment:
I can't yet reproduce on my system, but after looking at the code, I believe
the following are closer to the cause:
format(1, u'n')
int.__format__(1, u'n')
Incidentally, on my system, the following note in the docs is wrong:
Note: format(value
Chris Jerdonek added the comment:
The case with 1.__format__ is confusing the parser.
Interesting, good catch! That error did seem unusual. The two modified forms
do give the same result as int.__format__() (though the type still differs
New submission from Chris Jerdonek:
format(value) and value.__format__() behave differently even though the
documentation says otherwise:
Note: format(value, format_spec) merely calls value.__format__(format_spec).
(from http://docs.python.org/library/functions.html?#format )
The difference
Chris Jerdonek added the comment:
I filed issue 15952 for the behavior difference between format(value) and
value.__format__() and the related lack of documentation re: unicode format
strings.
Given that the expected behavior for the current issue doesn't seem to be
documented (aside from
Chris Jerdonek added the comment:
I did some analysis of this issue.
For starters, I could not reproduce this on Mac OS X 10.7.4. I iterated
through all available locales, and the separator was ASCII in all cases.
Instead, I was able to fake the issue by changing , to \xa0 in the
following
Chris Jerdonek added the comment:
I would recommend making the added and modified lines not exceed 79 characters
in both files. Also, for the .rst file, you can use slashes to break lines as
shown in the following example:
http://hg.python.org/cpython/file/09011896374d/Doc/library
Chris Jerdonek added the comment:
Also, while not strictly necessary, it is more customary and convenient to
provide a single patch file for all files.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14570
New submission from Chris Jerdonek:
docs.python.org doesn't seem to be getting updated anymore. For example, this
revision from Tuesday, Sept 11 is not reflected:
http://hg.python.org/cpython/rev/c8d60d0c736b
--
assignee: docs@python
components: Documentation
messages: 170525
nosy
Chris Jerdonek added the comment:
I also notice that there is an unnecessary call to time.sleep(0.1) whenever the
loop exhausts. This adds .1 seconds to the test run for every call to
test_today() on, for example, platforms that never get the same value twice
(according to the code comment
Chris Jerdonek added the comment:
I think this would be useful as well. For example, it would let one more
easily get finer-grained test result data (e.g. to the level of doctest
examples rather than just the TestCase level). Without this, I needed to
monkey patch.
The previously attached
Chris Jerdonek added the comment:
Here are the 6 cases where it always exhausts on my system:
test_today (test.datetimetester.TestSubclassDateTime_Pure)
test_today (test.datetimetester.TestDateTimeTZ_Pure)
test_today (test.datetimetester.TestDateTime_Pure)
test_today
Chris Jerdonek added the comment:
I think we can avoid unnecessary sleeps if we only loop again if the final
assert fails (i.e. by including the or condition with the time delta
allowance inside the loop and not just outside).
--
___
Python tracker
Chris Jerdonek added the comment:
if today == todayagain:
-break
+return # test passed
Might it make more sense to do the passing time-delta check inside the loop (at
the above location), and then raise an exception at the end if the loop
exhausts? I think
Chris Jerdonek added the comment:
That won't always work for case 1 (when theclass is e.g. 'date') and for case
4 (even if it's unlikely).
Can you explain what you mean by this? It seems the timedelta allowance would
be equally valid and serve the same purpose no matter what case
Chris Jerdonek added the comment:
Thanks, Ezio!
By the way, I didn't do a thorough check, but I noticed this difference in the
2.7 application of the patch. The *key* argument for max() needs to be marked
keyword-only. This difference doesn't exist for the min() function. Or are we
Chris Jerdonek added the comment:
Someone pointed out that keyword-only arguments were introduced only in 3.0,
but I'm not sure whether that means we can't use them as a notational device in
the 2.7 docs.
--
___
Python tracker rep
Chris Jerdonek added the comment:
If this looks good, can one of you three (Steven, Barry, or David) commit it in
the three branches?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15935
Chris Jerdonek added the comment:
Since the bare * notation wasn't added until 3.0, my guess is that we want to
remove the * below (from the 2.7 application of the patch) rather than adding
it back in the max() function I pasted above:
-.. function:: min(iterable[, args...][key])
+.. function
901 - 1000 of 1573 matches
Mail list logo
