Mark Dickinson dicki...@gmail.com added the comment:
Merged to py3k in r77146.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7534
___
Changes by Mark Dickinson dicki...@gmail.com:
--
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7534
___
___
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: - mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7534
___
___
Mark Dickinson dicki...@gmail.com added the comment:
Thanks for this; I'll take a look.
Looks like we need some tests for this, too.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7534
Mark Dickinson dicki...@gmail.com added the comment:
Here's a set of testcases (patch against trunk) for float pow, based on
Annex F of the C99 specification.
--
keywords: +patch
Added file: http://bugs.python.org/file15607/float_pow_testcases.patch
of -0.0. Here are corrected and
slightly expanded tests; I've also fixed an incorrect doctest (0**nan
should be nan, not 0) in Lib/test/ieee754.txt.
--
Added file: http://bugs.python.org/file15610/float_pow_testcases2.patch
___
Python tracker rep
Mark Dickinson dicki...@gmail.com added the comment:
Okay; I had to rework Marcos' patch a bit to get all the tests to pass.
Here's the result.
I propose making these changes only in 2.7 and 3.2, not in 2.6 or 3.1;
it's just possible that there's code out there that relies on some of
the
Marcos Donolo mdon...@vt.edu added the comment:
Ok, I have patch ready. how do we go about putting it in?
thanks.
marcos
On Thu, Dec 17, 2009 at 11:52 AM, Ezio Melotti rep...@bugs.python.orgwrote:
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
versions:
Ezio Melotti ezio.melo...@gmail.com added the comment:
Just upload it here clicking on 'Browse' next to the 'File' field and
then click on 'Submit Changes'.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7534
Changes by Marcos Donolo mdon...@vt.edu:
Added file: http://bugs.python.org/file15597/floatobject.c
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7534
___
Marcos Donolo mdon...@vt.edu added the comment:
I had to handle nans and infs in different places.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7534
___
New submission from Marcos Donolo mdon...@vt.edu:
I am not getting the expected result for the ** operator on windows,
python 2.6
I do...
a=float('nan')
b=a*a
then b is nan which is right but if I do
b = a**2 I get.
Traceback (most recent call last):
File stdin, line 1, in module
ValueError
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +mark.dickinson
priority: - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7534
___
Mark Dickinson dicki...@gmail.com added the comment:
Yep. There's not much consistency in inf/nan handling across platforms,
though the situation is slowly getting better. math.pow makes an effort
to handle these special cases correctly (for some value of correctly), and
it would probably
Mark Dickinson dicki...@gmail.com added the comment:
Closed 7536 as a duplicate of this issue.
--
title: float('nan')**2 != nan. float('nan')**2 error 33 on windows -
float('nan')**2 != nan. float('inf')**2 != inf. float('nan')**2 error 33 on
windows
Marcos Donolo mdon...@vt.edu added the comment:
I will give it a shot.
On Thu, Dec 17, 2009 at 11:22 AM, Mark Dickinson rep...@bugs.python.orgwrote:
Mark Dickinson dicki...@gmail.com added the comment:
Yep. There's not much consistency in inf/nan handling across platforms,
though
Mark Dickinson dicki...@gmail.com added the comment:
Great! For math.pow, see the function math_pow in Modules/mathmodule.c;
some sort of (careful!) cut-and-paste job from there to float_pow in
Objects/floatobject.c might do the trick.
--
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
versions: +Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7534
___
Mark Dickinson dicki...@gmail.com added the comment:
Yes, I don't think Python 2.6 had a deliberate workaround. I suspect
that it's just that one version of Python happened to use something like
0.0/0.0 to generate NaN, while another used some equivalent of
strtod(nan, ...).
I also remember
Mark Dickinson dicki...@gmail.com added the comment:
Just to confirm the above:
In 2.6, PyFloat_FromString in Objects/floatobject.c ends up using the
system strtod to parse nan and -nan (except that if the system
strtod fails to recognise nan for some reason then it returns the
result of 0.0
an example:
#include stdio.h
#include math.h
int main(void)
{
double x = NAN;
printf(%f %f\n, x, copysign(1.0, x));
return 0;
}
This gives -NaN, -1.00 with suncc and NaN, 1.00 with gcc.
Back to Python:
sys.float_repr_style is 'legacy'.
It looks like the C99
New submission from Stefan Krah stefan-use...@bytereef.org:
Sorry to report so many obscure corner cases. With the combination
Opensolaris/suncc/Python3.x copysign() gives reversed results when the
second argument is a NaN. The bug is in the C99 copysign() function
(OpenSolaris/suncc
for HAVE_PY_SET_53BIT_PRECISION in
Include/pyport.h for details.
Having said that, I don't really see this difference with nans as an
actual bug. Is it possible that float(nan) is simply giving a nan
with its sign bit set here, and that float(-nan) is giving a nan with
no sign bit set? That would
Stefan Krah stefan-use...@bytereef.org added the comment:
This whole thing is indeed a matter of taste, so I'd close the bug if no
one else is interested.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7049
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I would like to look at this for a bit before it gets closed.
--
assignee: mark.dickinson - rhettinger
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
Mark Dickinson dicki...@gmail.com added the comment:
Raymond, can I recommend deprecating and eventually removing three-
argument pow support from Decimal?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7049
Stefan Krah stefan-use...@bytereef.org added the comment:
Deprecate on the grounds that it is slow in decimal.py or the
InvalidOperation issue?
I think pure integer arithmetic with the decimal type always requires
attention from the user, since in many functions one has to check for
Mark Dickinson dicki...@gmail.com added the comment:
I was suggesting that it be deprecated on the grounds that:
(1) It's not part of the Decimal standard.
(2) It's not implemented for Python (binary) floats, so why implement
it for decimal floats?
(3) It's severely use-case challenged.
Stefan Krah stefan-use...@bytereef.org added the comment:
(1) is clearly true. I wonder about (2) and (3):
The decimal data type is specified to be usable for integer arithmetic.
With a high precision (and traps for Rounded/Inexact) I think it's
reasonably convenient to use.
--
Mark Dickinson dicki...@gmail.com added the comment:
Shrug. That doesn't really bother me. x**y%z and pow(x, y, z) aren't
going to match anyway, as soon as x**y has to be rounded.
What would bother me more is the idea of having, with precision 4:
pow(3, 22, 12347) - nan
pow(3, 23, 12347
New submission from Stefan Krah stefan-use...@bytereef.org:
decimal.py sets InvalidOperation if the payload of a NaN is too large:
c = getcontext()
c.prec = 4
c.create_decimal(NaN12345)
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.7/decimal.py
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7047
___
___
New submission from Stefan Krah stefan-use...@bytereef.org:
If precision 1 is aupported, the following results should not be NaN:
Python 2.7a0 (trunk:74738, Sep 10 2009, 11:50:08)
[GCC 4.3.2] on linux2
Type help, copyright, credits or license for more information.
from decimal import
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7049
___
___
,
diagnostic info too long in NaN)
and again, the Context._raise_error method translates the
ConversionSyntax exceptional condition to the corresponding
InvalidOperation signal.
Closing as a duplicate, just so we can keep everything one place.
--
resolution: - duplicate
status: open
Mark Dickinson dicki...@gmail.com added the comment:
This behaviour was deliberate: since the standard doesn't cover three-
argument pow, I more-or-less made up my own rules here. :)
In this case, I (somewhat arbitrarily) decided that to ensure that any
possible pow(a, b, m) result could be
Mark Dickinson dicki...@gmail.com added the comment:
Unless anyone else disagrees, I'm going to call this a 'won't fix': I'm
happy with the current behaviour. I would like to relax the condition on
the modulus from 'modulus 10**prec' to 'modulus = 10**prec', though, so
I'm leaving the
Mark Dickinson dicki...@gmail.com added the comment:
Here's a patch.
--
keywords: +patch
Added file: http://bugs.python.org/file15031/issue7049.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7049
Stefan Krah stefan-use...@bytereef.org added the comment:
I don't think early abortion based on m and the current precision is a
good idea. Then we have the situation that this works (prec=4):
(Decimal(7) ** 2) % 10
But this does not:
pow(Decimal(7), 2, 10)
--
On Sep 14, 4:05 pm, Scott David Daniels scott.dani...@acm.org wrote:
Steven D'Aprano wrote:
On Sun, 13 Sep 2009 17:58:14 -0500, Robert Kern wrote:
Exactly -- there are 2**53 distinct floats on most IEEE systems, the vast
majority of which might as well be random. What's the point of caching
En Sun, 13 Sep 2009 20:53:26 -0300, Steven D'Aprano
st...@remove-this-cybersource.com.au escribió:
There may be something to be said for caching common floats, like pi,
small integers (0.0, 1.0, 2.0, ...), 0.5, 0.25 and similar, but I doubt
the memory savings would be worth the extra
Steven D'Aprano wrote:
On Sun, 13 Sep 2009 17:58:14 -0500, Robert Kern wrote:
Exactly -- there are 2**53 distinct floats on most IEEE systems, the vast
majority of which might as well be random. What's the point of caching
numbers like 2.5209481723210079? Chances are it will never come up
Gabriel Genellina wrote:
En Sun, 13 Sep 2009 20:53:26 -0300, Steven D'Aprano
st...@remove-this-cybersource.com.au escribió:
There may be something to be said for caching common floats, like pi,
small integers (0.0, 1.0, 2.0, ...), 0.5, 0.25 and similar, but I doubt
the memory savings would be
numpy.ndarray objects to disk which are of type float,
but which may include NaN in some cells. When I unpickle these
objects and then test for the presence of NaN, the test fails. Here's
a minimal sample program, and its output:
=== program
## numpy
have a problem with numpy, or with
my understanding of the Python pickle module, so I'm posting here.
I am pickling numpy.ndarray objects to disk which are of type float,
but which may include NaN in some cells. When I unpickle these
objects and then test for the presence of NaN, the test fails
arrays are never guaranteed.
Usually, they will always be different. You need to use numpy.isnan() to
determine whether an object is a NaN.
OK, so there's a dedicated function in numpy to handle this. Thanks!
I tried x is NaN after noting the obvious, that any equality or
inequality test
John Ladasky wrote:
OK, so there's a dedicated function in numpy to handle this. Thanks!
I tried x is NaN after noting the obvious, that any equality or
inequality test involving NaN will return False.
In my leisure time, I would like to dig deeper into the issue of why
object identities
John Ladasky wrote:
In my leisure time, I would like to dig deeper into the issue of why
object identities are not guaranteed for elements in numpy arrays...
with elements of type float, at least, I thought this would be
trivial.
Why do you think that? We would have to keep a reference around
On Sep 13, 3:18 pm, John Ladasky john_lada...@sbcglobal.net wrote:
In my leisure time, I would like to dig deeper into the issue of why
object identities are not guaranteed for elements in numpy arrays...
with elements of type float, at least, I thought this would be
trivial.
Unlike Python
On Sun, 13 Sep 2009 17:58:14 -0500, Robert Kern wrote:
John Ladasky wrote:
In my leisure time, I would like to dig deeper into the issue of why
object identities are not guaranteed for elements in numpy arrays...
with elements of type float, at least, I thought this would be
trivial.
On Sep 13, 4:17 pm, Carl Banks pavlovevide...@gmail.com wrote:
On Sep 13, 3:18 pm, John Ladasky john_lada...@sbcglobal.net wrote:
In my leisure time, I would like to dig deeper into the issue of why
object identities are not guaranteed for elements in numpy arrays...
with elements of type
).compare_total_mag(Decimal(-NaN99))
== Decimal('-1')
Should be: Decimal('1') (checked against decNumber)
--
components: Library (Lib)
messages: 92032
nosy: skrah
severity: normal
status: open
title: decimal.py: incorrect results in NaN comparisons
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +marketdickinson
priority: - normal
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6794
___
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: - marketdickinson
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6794
___
Mark Dickinson dicki...@gmail.com added the comment:
Thanks for the report! I've applied a quick fix in the trunk in r74564;
merged to other branches in r74565 (release26-maint), r74566 (py3k) and
r74567 (release31-maint).
--
resolution: - fixed
stage: - committed/rejected
status:
Eric Smith e...@trueblade.com added the comment:
I believe this is a duplicate of issue 4482. I'm closing this and will
add everyone who is nosy on this to be nosy on 4482.
--
resolution: - duplicate
status: open - closed
___
Python tracker
Christoph Zwerschke c...@online.de added the comment:
This is a related problem on Windows:
'%g' % 1e400 - '1.#INF'
'%.f' % 1e400 -- '1'
--
nosy: +cito
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4799
Mark Dickinson dicki...@gmail.com added the comment:
Assigning to Eric, at his request.
--
assignee: marketdickinson - eric.smith
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4799
Mark Dickinson dicki...@gmail.com added the comment:
Thanks Martin and Mark Miller for the comments and testing.
I'm going to close this as won't fix. This doesn't preclude ARM OABI
becoming a supported platform at some point in the future, just not
right now.
--
resolution: - wont
Mark Miller m...@mirell.org added the comment:
This still occurs in the latest SVN checkout, and is preventing Python
from building on ARMV4L and ARMV5L OABI, dying during the test_float.py
compilation. The patch appears to solve this problem, however I have not
run a full suite of tests to
Mark Dickinson dicki...@gmail.com added the comment:
I'll take a look at this, provided Tim doesn't mind me stealing his
issue. (Please steal it back if so.)
Mark, could you please post the output from test_float?
--
assignee: tim_one - marketdickinson
nosy: +marketdickinson
Mark Miller m...@mirell.org added the comment:
The following is where it fails un-patched:
Compiling /usr/local/lib/python2.6/test/test_float.py ...
Traceback (most recent call last):
File /usr/local/lib/python2.6/compileall.py, line 156, in module
exit_status = int(not main())
File
Mark Dickinson dicki...@gmail.com added the comment:
Thanks, Mark.
A few comments:
- The patch seems incomplete. There are other places in the source tree
that care about endianness. I haven't done a thorough search, but the
native endianness support in the struct module comes to mind.
Mark Dickinson dicki...@gmail.com added the comment:
native endianness support in the struct module comes to mind
Sorry: ignore that. The patch already covers this, since the struct
module just uses _PyFloat_{Unp,P}ack8.
___
Python tracker
Mark Dickinson dicki...@gmail.com added the comment:
We still need to fix the compile failure somehow, though...
Mark, is there any way you can isolate the test(s) in test_float that are
causing compile failure? I'm suspicious of test_inf_as_str and
test_nan_as_str. Does test_float compile
Mark Dickinson dicki...@gmail.com added the comment:
I think my -1 for adding the new format was premature: I was hoping to
find a way to fix marshal for the 'unknown' format, but the cleanest
solution does indeed appear to be to add the mixed-endian format. And
apart from the
Martin v. Löwis mar...@v.loewis.de added the comment:
I'm still not sure whether this can be a candidate 2.6 and 3.0. Martin,
do you have any thoughts on this?
I think this qualifies as a new port. In the past, we have avoided
adding new ports in bugfix releases.
As for adding it to
Mark Miller m...@mirell.org added the comment:
I am in a position to test as much as needed. I am attempting to get
Gentoo's ARM/MIPS/Embedded distribution up to date on Python, and
noticed this build break. (Typically most embedded architectures are
several releases behind.)
I'll try this new
Mark Miller m...@mirell.org added the comment:
The new patch works correctly, by the way, on ARMv4L and ARMv5L OABI boards.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1762561
___
Changes by Martin v. Löwis mar...@v.loewis.de:
--
versions: -Python 2.5, Python 2.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1762561
___
___
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: - marketdickinson
nosy: +marketdickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4799
___
Daniel Diniz aja...@gmail.com added the comment:
OP posted a message in python-dev, with no replies:
http://mail.python.org/pipermail/python-dev/2007-June/073625.html
--
nosy: +ajaksu2, marketdickinson
versions: +Python 2.7, Python 3.1 -Python 2.6
Mark Dickinson dicki...@gmail.com added the comment:
I don't see a huge need for this. In 2.6, 3.0 and higher, float(repr(x))
recovers x reliably across platforms
(modulo the occasional system strtod bug), even when x is an infinity or nan.
It's true that using float() doesn't help if you
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: - marketdickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1732212
___
___
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
Recommend closing this. We like to have eval(repr(obj))==obj where
possible but it is not a strict requirement. Am opposed to the two
proposed solutions (float attributes or new literals). Mark's solution
of defining nan
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1732212
___
Mark Dickinson dicki...@gmail.com added the comment:
Closing this one as won't fix.
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2121
___
Mark Dickinson dicki...@gmail.com added the comment:
[Mark]
inputs with a special real or imaginary component. On balance, I'd
support making complex('nan + nan*j') do the right thing.
Having thought about this a bit more, I take this back. Some reasons are
given below.
[David
Mark Dickinson dicki...@gmail.com added the comment:
Christian, any comments? Is it okay to close this as a 'won't fix'?
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2121
___
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment:
@ Mark
Concerning float('inf') * 1j: you're right, my rambling did not make any
sense, sorry.
I agree that adding complexity may be a good reason to warrant an
arbitrary feature; actually, I did not manage to handle nan/inf
be pursued. I see no utility in pairs like (NaN, 3.0) or
(-2.0, Inf). The whole request is use case challenged. AFAICT, the
current implementation suffice for real cases and there is no compelling
need to rearrange and redesign this code.
___
Python tracker
these infinities. But the cmath module *does* make an
effort to return the 'correct' (according to C99 Annex G) values for
inputs with a special real or imaginary component. On balance, I'd
support making complex('nan + nan*j') do the right thing.
(Though I can't help feeling that the repr
Mark Dickinson dicki...@gmail.com added the comment:
cdavid, in your application, how hard is it to work around the problem by
simply printing and parsing pairs of floats rather than complex numbers?
E.g.,
get real part and imaginary part from string
z = complex(float(real_part),
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment:
It is not really for an application, but for numpy. Of course, one can
always get around the problem - but since this is really a limitation
which can be easily fixed, why not fixing the problem :) ?
a very real problem: incidently,
I got interested in this patch while working on numpy, and it is
certainly useful to be able to parse nan and inf (for example when we
create arrays from strings). Nan may be seen as non useful for so called
real usage of python, but for scientific people
real-world use cases arise.
... for scientific people, it is a crucial to have proper support
of nan (which may mean missing data depending on the context) and inf.
Mark, does Inf have a standard interpretation for complex numbers? Do
all infinities meet or do they radiate, each with their own
and test.
Yes, it is difficult to handle nan and inf, there are a lot of corner
cases. But I fail to see how this applies here: my patch is essentially
a rewrote of the parsing, and the code to handle nan/inf is only 7
lines. This is independent of the handling of how nan/inf is handled by
math
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment:
Ok, I found out how to make tests, and I found some problems while using
this on numpy. A third version of the patch, with unit tests: all tests
in test_complex.py pass.
Added file: http://bugs.python.org/file12504/nan_parse.patch
Changes by Cournapeau David da...@ar.media.kyoto-u.ac.jp:
Removed file: http://bugs.python.org/file12503/nan_parse.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2121
___
Changes by Cournapeau David da...@ar.media.kyoto-u.ac.jp:
Removed file: http://bugs.python.org/file12502/nan_parse.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2121
___
nosy: cdavid
severity: normal
status: open
title: handling inf/nan in '%f'
versions: Python 2.6
Added file: http://bugs.python.org/file12518/nan.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4799
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment:
I started a patch against the trunk to handle nan/inf/infinite (I have
not yet tackled the problem of negative zero).
The patch is a bit big, because I found the function quite difficult to
follow, so I refactored it a bit first
Cournapeau David da...@ar.media.kyoto-u.ac.jp added the comment:
Of course, I notice two bugs just after sending the patch... New patch
to fix those two issues (no check for closing bracket if opening ones
are there and a bug when only imaginary part is given).
Added file:
Mark Dickinson [EMAIL PROTECTED] added the comment:
Merged to 2.6 and 3.0 maintenance branches (r67700, r67701).
--
resolution: - fixed
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4084
Martin v. Löwis [EMAIL PROTECTED] added the comment:
Unless Facundo or some of the other decimal contributors reviews and
applies this patch really quickly, it is out of scope for 2.5.3.
--
nosy: +loewis
___
Python tracker [EMAIL PROTECTED]
Facundo Batista [EMAIL PROTECTED] added the comment:
Commited in trunk and Py3, thanks Mark!
Please, could you commit it in 2.5? The only change I've made in the
patch is adding the issue number to Misc/NEWS, the rest is ok.
After that, just close this.
Thanks again!
--
versions:
Martin v. Löwis [EMAIL PROTECTED] added the comment:
Mark, if you want to backport this, please go ahead. If want me to,
assign to me.
--
assignee: facundobatista - marketdickinson
priority: normal - release blocker
___
Python tracker [EMAIL
Changes by Mark Dickinson [EMAIL PROTECTED]:
--
versions: +Python 3.1
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4084
___
___
Python-bugs-list
Changes by Mark Dickinson [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11989/issue4296.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4296
___
Mark Dickinson [EMAIL PROTECTED] added the comment:
Before committing, please add one
other test that verifies the relationship between in in membership
tests and in in a for-loop:
Added. (To test_contains, since this seems like a more appropriate place
than test_float.)
Added file:
901 - 1000 of 1188 matches
Mail list logo
