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:
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
<http://bugs.python.org/issue16
Chris Jerdonek added the comment:
Ezio, do you want to commit this or should I?
--
___
Python tracker
<http://bugs.python.org/issue16036>
___
___
Python-bug
Changes by Chris Rebert :
--
nosy: +cvrebert
___
Python tracker
<http://bugs.python.org/issue16048>
___
___
Python-bugs-list mailing list
Unsubscribe:
Chris Jerdonek added the comment:
>From http://bugs.python.org/review/16036/ for issue 16036:
> Somewhere should be exposed that x must be str, bytes, bytearray or a
> subclass.
We can add tests for this, too (if not already there).
--
_
Changes by Chris Jerdonek :
--
stage: -> needs patch
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue16056>
___
___
Python-bugs-list mai
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
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 trac
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.
New submission from Chris Jerdonek:
> Date: Thu, 13 Sep 2012 09:42:47 -0400
> To:
> Subject: [docs] Problem with the documentation for string.replace
>
> >From http://docs.python.org/library/string.html
>
> string.replace(str, old, new[,
> maxreplace])?<
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
> Comprehensions<http://docs.python.org/dev/tutorial/datastructures.html#list-comprehensions>
>
> List co
Chris Jerdonek added the comment:
Leaving open until the change is made in 2.7 (the current wording is somewhat
different there). I will do that in the next day or so.
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue16
New submission from Chris Jerdonek:
When pushing commits to hg.python.org, I got the following error re: the
"incoming.cia" hook:
$ hg push ssh://h...@hg.python.org/cpython
pushing to ssh://h...@hg.python.org/cpython
searching for changes
remote: adding changesets
remote: adding
New submission from Chris Jerdonek:
> Date: Thu, 6 Sep 2012 20:38:21 +0800
> To: d...@python.org
> Subject: [docs] There is bug about the built-in function reduce in the
> document
>
> I found a bug in the document about reduce :
> http://docs.python.org/library/
Chris Jerdonek added the comment:
It looks like the offending line is here:
http://hg.python.org/cpython/file/6ccb04c4cbae/Lib/unittest/__main__.py#l5
if sys.argv[0].endswith("__main__.py"):
sys.argv[0] = "python -m unittest"
--
n
Chris Jerdonek added the comment:
(I was just including the line for the convenience of anyone that might happen
to come across the issue. It was not to inform you of course! :) )
FWIW, if you already know from talking to Michael or looking at the code, I
think a comment saying why sys.argv
Chris Jerdonek added the comment:
I should have said that I had started working on this issue. I think failing
tests for both messages should accompany the patch (otherwise I would have
already submitted a patch). The tricky one is the error message for
PyLong_FromString(), which I believe
1501 - 1600 of 2758 matches
Mail list logo
