New submission from Chris Jerdonek:
This issue is to add to the doctest module an easy way to obtain the number of
doctest examples in a unittest.TestSuite instance returned by a call to the
doctest.DocFileSuite() function.
The unittest.TestSuite class currently exposes a countTestCases
New submission from Chris Jerdonek:
Currently, when trying to parse the *.rst files in the Doc/ folder (i.e. not
actually running them but simply generating unittest.TestCase instances from
them by passing them to doctest.DocFileSuite()), five files yield errors.
This issue is to make it so
Chris Jerdonek added the comment:
> # The return value of DocFileSuite is a unittest.TestCase instance, and
s/unittest.TestCase/unittest.TestSuite/ (as elsewhere in the comment)
--
___
Python tracker
<http://bugs.python.org/issu
Chris Jerdonek added the comment:
The attached patch addresses all but Doc/library/ctypes.rst.
See the following python-dev e-mail for a question about how best to handle
that case:
http://mail.python.org/pipermail/python-dev/2012-September/121721.html
--
keywords: +patch
Added file
Changes by Chris Jerdonek :
Removed file: http://bugs.python.org/file27185/issue-15935-1.patch
___
Python tracker
<http://bugs.python.org/issue15939>
___
___
Python-bug
Changes by Chris Jerdonek :
Added file: http://bugs.python.org/file27186/issue-15939-1.patch
___
Python tracker
<http://bugs.python.org/issue15939>
___
___
Python-bug
Chris Jerdonek added the comment:
Attached is a file of doctest statistics (counts of example failures,
exceptions, and successes) for almost every file in the Doc directory when
running the doctests with vanilla doctest.
I did this to get a sense of which files it would be easiest to get
Chris Jerdonek added the comment:
Thanks for committing, Ezio!
--
___
Python tracker
<http://bugs.python.org/issue15437>
___
___
Python-bugs-list mailin
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 a
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 trac
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
<http://bugs.python.org/issue15
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])
+.. fun
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
<http://bugs.python.org/issue14
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
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 co
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).
--
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 purp
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
<http://bugs.pyth
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&
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
<http://bugs.python.org/is
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&
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 followin
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 diff
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?#for
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
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 &qu
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/cp
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/19601d4
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 s
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 obje
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 trac
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
Chris Jerdonek added the comment:
What about patch_object()?
--
___
Python tracker
<http://bugs.python.org/issue11664>
___
___
Python-bugs-list mailing list
Unsub
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:
> 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 manage
Changes by Chris Jerdonek :
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issue6471>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
<http://bugs.pyt
Chris Jerdonek added the comment:
It has been 8 days since the last update.
--
priority: normal -> high
___
Python tracker
<http://bugs.python.org/issu
Changes by Chris Jerdonek :
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issue10967>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 partic
Chris Jerdonek added the comment:
Thanks, Ezio!
--
___
Python tracker
<http://bugs.python.org/issue14873>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Chris Jerdonek :
--
nosy: +ezio.melotti
___
Python tracker
<http://bugs.python.org/issue15939>
___
___
Python-bugs-list mailing list
Unsubscribe:
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_o
Changes by Chris Jerdonek :
--
nosy: +loewis, ned.deily
___
Python tracker
<http://bugs.python.org/issue15949>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 f
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 c
Chris Jerdonek added the comment:
Thanks for the quick commit, Mark. :)
--
___
Python tracker
<http://bugs.python.org/issue15985>
___
___
Python-bugs-list mailin
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
<http://bugs.python.org/issue15304>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 examp
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" secti
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
<http://bugs.python.org/issue15
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
<http://bugs.python.org/issue15
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: +Devgu
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&#
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 c
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 fac
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
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
<http://bugs.python.o
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.or
Changes by Chris Jerdonek :
--
nosy: +ezio.melotti
___
Python tracker
<http://bugs.python.org/issue15952>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Chris Jerdonek :
--
nosy: +ezio.melotti
___
Python tracker
<http://bugs.python.org/issue15951>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Chris Jerdonek :
--
nosy: +ezio.melotti
___
Python tracker
<http://bugs.python.org/issue15935>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
> 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
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 "
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
--
Changes by Chris Jerdonek :
--
keywords: +needs review
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue15964>
___
___
Python-
Changes by Chris Jerdonek :
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issue15034>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Chris Jerdonek :
--
nosy: +cjerdonek
___
Python tracker
<http://bugs.python.org/issue13440>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 se
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."""
An
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.
--
no
Changes by Chris Jerdonek :
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue7897>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.pyt
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
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.jer
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
s
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'
Chris Jerdonek added the comment:
- :meth:`close`\ d without adding any files to the archive, the appropriate
+ :meth:`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 like
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
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
___
Py
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
titl
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
<http://bugs.python.org/issue16
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.
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/
Chris Jerdonek added the comment:
Good improvement. LGTM.
--
___
Python tracker
<http://bugs.python.org/issue16036>
___
___
Python-bugs-list mailing list
Unsub
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 "", line 1, in
ValueError: int() arg 2 must be >= 2 and <= 36
The *base* argument can al
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
Changes by Chris Jerdonek :
--
nosy: +chris.jerdonek
___
Python tracker
<http://bugs.python.org/issue16056>
___
___
Python-bugs-list mailing list
Unsubscribe:
801 - 900 of 1575 matches
Mail list logo
