[issue4296] Python assumes identity implies equivalence; contradicts NaN
Mark Dickinson [EMAIL PROTECTED] added the comment:
This is indeed interesting. For what it's worth, I think
the Python 3.0 behaviour is the right one, here. Perhaps
it's worth adding a test to Python 3.0 to make sure that
this behaviour doesn't accidentally disappear, or at least
to make sure that someone thinks about it before making
the behaviour disappear.
But in general I don't think the fact that NaNs are weird
should get in the way of optimizations. In other words,
I'm not sure that Python should be asked to guarantee
anything more than b == b returning False when b is
a NaN. It wouldn't seem unreasonable to consider
behaviour of nans in containers (sets, lists, dicts)
as undefined when it comes to equality and identity
checks.
There are other questionable things going on when NaNs
are put into containers. For example:
a = float('nan')
b = [a]
a in b
True
A strict reading of the definition of 'in' would say
that a in b should return False here, since a is not
equal to any element of b. But I presume that the 'in'
operator does identity checks under the hood before
testing for equality. 'Fixing' this so that nans did
the right thing might slow down a lot of other code
just to handle one peculiar special case correctly.
Michael, is this adversely affecting real-world code?
If not, I'd be inclined to say that it's not worth
changing Python's behaviour here.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4296
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Mark Dickinson [EMAIL PROTECTED] added the comment: [Raymond] assuming basic invariants. In 2.6, all of the following are always true: assert a in [a] assert a in (a,) assert a in set([a]) assert [a].count(a) == 1 And these are all still true in 3.0 as well, aren't they? In any case, you've convinced me. I withdraw my comment about the Python 3.0 behaviour being the right one. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Raymond Hettinger [EMAIL PROTECTED] added the comment:
To be clear, I'm saying that PyObject_RichCompareBool() needs to
add-back the code:
/* Quick result when objects are the same.
Guarantees that identity implies equality. */
if (v == w) {
if (op == Py_EQ)
return 1;
else if (op == Py_NE)
return 0;
}
When the above code was originally put in, there was discussion about it
on python-dev and time has proven it to be a successful choice.
I don't know who took this out, but taking it out was a mistake in a
world that allows rich comparison functions to return anything they
want, possibly screwing-up the basic invariants everywhere we do
membership testing.
Taking it out probably had something to do with NaNs, but this
discussion needs to avoid getting lost in NaN paradoxes and instead
focus on a notion of membership that is ALWAYS true given object
identity. This is an essential pragmatism necessary for reasoning about
programs.
Consider that while PyObject_RichCompare() can return any object and can
be used in varied and sundry ways, the opposite is true for
PyObject_RichCompareBool(). The latter always returns a boolean and its
internal use cases are almost always ones that assume the traditional
properties of equality -- a binary relation or predicate that is
reflexive, symmetric, and transitive. We let the == operator violate
those properties, but the calls to PyObject_RichCompareBool() tend to
DEPEND on them.
---
P.S. Mark, those Py2.6 invariants are not still true in Py3.0:
IDLE 3.0rc2
a = float('nan')
a in [a]
False
a in (a,)
False
a in set([a])
True
[a].count(a)
0
for x in container:
assert x in container
AssertionError
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4296
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4298] pickle segfault or MemoryError on invalid input
New submission from Hagen Fürstenau [EMAIL PROTECTED]: On a 64-bit build pickle.loads segfaults on the following bytes. (Same for pickle.load on a corresponding file.) On a 32-bit build there is only a MemoryError. Python 3.0rc2 (r30rc2:67114, Nov 10 2008, 12:09:54) [GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2 Type help, copyright, credits or license for more information. import pickle pickle.loads(bytes([0x58, 0, 0, 0, 0x54])) Segmentation fault -- components: Library (Lib) messages: 75743 nosy: hagen severity: normal status: open title: pickle segfault or MemoryError on invalid input type: crash versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4299] 3.0rc2.msi Install Fails (Error Code 2755)
New submission from Gary VanHorn [EMAIL PROTECTED]: Where can an error code resource be found? -- components: Installation messages: 75744 nosy: sharksuit severity: normal status: open title: 3.0rc2.msi Install Fails (Error Code 2755) versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4299 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Michael B Curtis [EMAIL PROTECTED] added the comment: All, Thank you for your rigorous analysis of this bug. To answer the question of the impact of this bug: the real issue that caused problems for our application was Python deciding to silently cast NaN falues to 0L, as discussed here: http://mail.python.org/pipermail/python-dev/2008-January/075865.html This would cause us to erroneously recognize 0s in our dataset when our input was invalid, which caused various issues. Per that thread, it sounds like there is no intention to fix this for versions prior to 3.0, so I decided to detect NaN values early on with the following: def IsNan(x): return (x is x) and (x != x) This is not the most rigorous check, but since our inputs are expected to be restricted to N-dimensional lists of numeric and/or string values, this was sufficient for our purposes. However, I wanted to be clear as to what would happen if this were handed a vector or matrix containing a NaN, so I did a quick check, which led me to this bug. My workaround is to manually avoid the optimization, with the following code: def IsNan(x): if isinstance(x, list) or isinstance(x, tuple) or isinstance(x, set): for i in x: if IsNan(i): return True return False else: return (x is x) and (x != x) This isn't particularly pretty, but since our inputs are relatively constrained, and since this isn't performance-critical code, it suffices for our purposes. For anyone working with large datasets, this would be suboptimal. (As an aside, if someone has a better solution for a general-case NaN-checker, which I'm sure someone does, feel free to let me know what it is). Additionally, while I believe that it is most correct to say that a list containing NaN is not equal to itself, I would hesitate to claim that it is even what most applications would desire. I could easily imagine individuals who would only wish for the list to be considered NaN-like if all of its values are NaN. Of course, that wouldn't be solved by any changes that might be made here. Once one gets into that level of detail, I think the programmer needs to implement the check manually to guarantee any particular expected outcome. Returning to the matter at hand: while I cringe to know that there is this inconsistency in the language, as a realist I completely agree that it would be unreasonable to remove the optimization to preserve this very odd corner case. For this reason, I proposed a minimal solution here to be that this oddity merely be documented better. Thanks again for your thoughts. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Christian Heimes [EMAIL PROTECTED] added the comment: The issue with nan - 0L was fixed in Python 2.6. I can't recall if I fixed it or somebody else but I know it was discussed. $ python2.6 long(float(nan)) Traceback (most recent call last): File stdin, line 1, in module ValueError: cannot convert float NaN to integer long(float(inf)) Traceback (most recent call last): File stdin, line 1, in module OverflowError: cannot convert float infinity to integer ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4294] Macros for PyLong: sign, number of digits, fits in an int
Gregory P. Smith [EMAIL PROTECTED] added the comment: I agree with Christian that we should wait until 3.0 is out. Using A DVCS should make this much easier if anyone needs an excuse to learn bzr. I think we should aim to commit the 30bit change (a pretty clear win by the looks of things) after 3.0 is released and py3k branch is unfrozen and continue work from there to determine what to do with the others. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4294 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3439] create a numbits() method for int and long types
STINNER Victor [EMAIL PROTECTED] added the comment: (-maxint-1).numbits() hangs Ooops, nice catch! It was an integer overflow, already present in fredrikj's original patch. The new patch fixes this bug but also included a documentation patch ;-) Added file: http://bugs.python.org/file11988/numbits-3.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3439 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3439] create a numbits() method for int and long types
Changes by STINNER Victor [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file11939/numbits-2.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3439 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1673409] datetime module missing some important methods
Alexander Belopolsky [EMAIL PROTECTED] added the comment: Chris I keep needing to know the number of seconds that a timedelta Chris represents. I propose an alternative approach that I believe will neatly solve fractional vs. whole seconds and multitude of conceivable toxxx methods: Let's extend timedelta's div and floordiv methods to allow (t - epoch) // timedelta(seconds=1) -- whole seconds and (t - epoch) / timedelta(seconds=1) -- fractional seconds -- nosy: +belopolsky ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1673409 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4300] error in multiprocessing logging docs
New submission from Brian D'Urso [EMAIL PROTECTED]:
the 2.6 docs for the multiprocessing module have a minor error in the
logging example which causes it to fail:
the documentation says to get the logger with
'multiprocessing.get_logger()' which works
but the example uses 'multiprocessing.getLogger()' which uses the
logging package method name and is not valid.
The full example in the docs is:
import multiprocessing, logging
logger = multiprocessing.getLogger()
logger.setLevel(logging.INFO)
logger.warning('doomed')
[WARNING/MainProcess] doomed
m = multiprocessing.Manager()
[INFO/SyncManager-1] child process calling self.run()
[INFO/SyncManager-1] manager bound to '.\\pipe\\pyc-2776-0-lj0tfa'
del m
[INFO/MainProcess] sending shutdown message to manager
[INFO/SyncManager-1] manager exiting with exitcode 0
--
assignee: georg.brandl
components: Documentation
messages: 75755
nosy: dursobr, georg.brandl
severity: normal
status: open
title: error in multiprocessing logging docs
versions: Python 2.6
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4300
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Raymond Hettinger [EMAIL PROTECTED] added the comment: Mark, thanks for checking that all the tests still pass. Please do add back the missing lines in PyObject_RichCompareBool(). It seems that their removal was not a necessary part of eliminating default sort-ordering. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4301] incorrect and inconsistent logging in multiprocessing
New submission from Brian D'Urso [EMAIL PROTECTED]:
logging in multiprocessing seems to give inconsistent results on Linux
and XP, but neither appears to match the documentation:
According to the docs, when first created the logger has level
logging.NOTSET and has a handler which sends output to sys.stderr using
format '[%(levelname)s/%(processName)s] %(message)s' The example in the
docs also does not work, but the full problem is more clearly
illustrated with the following:
This should print a message from the main process and the subprocess:
import multiprocessing, logging
def f():
logger = multiprocessing.get_logger()
logger.info('info from subprocess')
if __name__ == '__main__':
logger = multiprocessing.get_logger()
logger.setLevel(logging.INFO)
logger.info('info from main process')
p = multiprocessing.Process(target=f)
p.start()
p.join()
but, on Windows (XP) and Linux (ScientificLinux 5.2, python 2.6 compiled
from src) it outputs only:
No handlers could be found for logger multiprocessing
We can 'fix' this by specifying a handler, as in:
import multiprocessing, logging
def f():
logger = multiprocessing.get_logger()
logger.info('info from subprocess')
if __name__ == '__main__':
logger = multiprocessing.get_logger()
logger.setLevel(logging.INFO)
handler = logging.StreamHandler()
handler.setLevel(logging.INFO)
formatter = logging.Formatter('[%(levelname)s/%(processName)s]
%(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.info('info from main process')
p = multiprocessing.Process(target=f)
p.start()
p.join()
Then on Linux I get:
[INFO/MainProcess] info from main process
[INFO/Process-1] child process calling self.run()
[INFO/Process-1] info from subprocess
[INFO/Process-1] process shutting down
[INFO/Process-1] process exiting with exitcode 0
[INFO/MainProcess] process shutting down
which looks better, but on Windows I get:
[INFO/MainProcess] info from main process
No handlers could be found for logger multiprocessing
[INFO/MainProcess] process shutting down
So, the logger is still not setup correctly in the subprocess on
Windows. We can again try to 'fix' this to:
import multiprocessing, logging
def f():
logger = multiprocessing.get_logger()
handler = logging.StreamHandler()
handler.setLevel(logging.INFO)
formatter = logging.Formatter('[%(levelname)s/%(processName)s]
%(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.info('info from subprocess')
if __name__ == '__main__':
logger = multiprocessing.get_logger()
logger.setLevel(logging.INFO)
handler = logging.StreamHandler()
handler.setLevel(logging.INFO)
formatter = logging.Formatter('[%(levelname)s/%(processName)s]
%(message)s')
handler.setFormatter(formatter)
logger.addHandler(handler)
logger.info('info from main process')
p = multiprocessing.Process(target=f)
p.start()
p.join()
Now, on Linux I get:
[INFO/MainProcess] info from main process
[INFO/Process-1] child process calling self.run()
[INFO/Process-1] info from subprocess
[INFO/Process-1] info from subprocess
[INFO/Process-1] process shutting down
[INFO/Process-1] process shutting down
[INFO/Process-1] process exiting with exitcode 0
[INFO/Process-1] process exiting with exitcode 0
[INFO/MainProcess] process shutting down
i.e. double output from the subprocess!
On Windows, I finally get:
[INFO/MainProcess] info from main process
No handlers could be found for logger multiprocessing
[INFO/Process-1] info from subprocess
[INFO/Process-1] process shutting down
[INFO/Process-1] process exiting with exitcode 0
[INFO/MainProcess] process shutting down
which is almost OK, but the logger is getting set up too late to pick up
the subprocess self.run
It seems like the logger is not being setup correctly by
multiprocessing.get_logger() and the behavior is different in a
subprocess on Windows vs Linux.
--
components: Library (Lib)
messages: 75757
nosy: dursobr
severity: normal
status: open
title: incorrect and inconsistent logging in multiprocessing
type: behavior
versions: Python 2.6
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4301
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4298] pickle segfault or MemoryError on invalid input
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Fixed in r67187. Thanks for the report, and for the patch! -- nosy: +amaury.forgeotdarc resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4185] re module treats raw strings as normal strings
Changes by A.M. Kuchling [EMAIL PROTECTED]: -- nosy: +akuchling ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4185 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Mark Dickinson [EMAIL PROTECTED] added the comment: Taking it out probably had something to do with NaNs, but this discussion needs to avoid getting lost in NaN paradoxes and instead focus on a notion of membership that is ALWAYS true given object identity. This is an essential pragmatism necessary for reasoning about programs. I agree wholeheartedly. NaN comparison weirdness isn't anywhere near important enough to justify breaking these invariants. Though I imagine that if 'x == x' started returning True for NaNs there might be some complaints. P.S. Mark, those Py2.6 invariants are not still true in Py3.0: You're right, of course. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4297] Add error_log attribute to optparse.OptionParser
New submission from Daniel Watkins [EMAIL PROTECTED]: I've recently had to subclass optparse.OptionParser, and copy-paste the exit method, just to change where errors were printed to (I needed stdout rather than stderr). I've also had a request from a client to log errors with command-line parsing to a file, rather than to stdout. So, this patch adds an error_log parameter to OptionParser.__init__ which is used instead of stderr internally (and, of course, defaults to stderr). -- components: Library (Lib) files: optparse-error_log.patch keywords: patch messages: 75741 nosy: odd_bloke severity: normal status: open title: Add error_log attribute to optparse.OptionParser type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file11985/optparse-error_log.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4297 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3439] create a numbits() method for int and long types
Mark Dickinson [EMAIL PROTECTED] added the comment: Hi, Victor! Thanks for the updated patch. Your patch still hangs on: from sys import maxint (-maxint-1).numbits() on my 32-bit machine. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3439 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4298] pickle segfault or MemoryError on invalid input
Hirokazu Yamamoto [EMAIL PROTECTED] added the comment:
See trunk/Modules/cPickle.c(609).
static Py_ssize_t
read_cStringIO(Unpicklerobject *self, char **s, Py_ssize_t n)
{
char *ptr;
if (PycStringIO-cread((PyObject *)self-file, ptr, n) != n) {
PyErr_SetNone(PyExc_EOFError);
return -1;
}
*s = ptr;
return n;
}
It's checking the length of returned string and if not match, raises
EOFError. But there is no corresponding code in py3k.
I hope attached patch will fix this issue.
--
keywords: +patch
nosy: +ocean-city
Added file:
http://bugs.python.org/file11987/py3k_set_EOFError_when_invalid_result_size.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4298
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Christian Heimes [EMAIL PROTECTED] added the comment: Here is a tes case for 3.0 -- keywords: +patch Added file: http://bugs.python.org/file11984/issue4296_test.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Mark Dickinson [EMAIL PROTECTED] added the comment:
One more data point: in both 2.x and 3.x, sets behave like the 2.x
lists:
Python 3.0rc2+ (py3k:67177M, Nov 10 2008, 16:06:34)
[GCC 4.0.1 (Apple Inc. build 5488)] on darwin
Type help, copyright, credits or license for more information.
s = {float('nan')}
s == s
True
s is s
True
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4296
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Raymond Hettinger [EMAIL PROTECTED] added the comment: I'm not happy with the 3.0 change. IMO, the best behavior is the one that allows code reviewers to correctly reason about the code by assuming basic invariants. In 2.6, all of the following are always true: assert a in [a] assert a in (a,) assert a in set([a]) assert [a].count(a) == 1 This is especially important because it lets us maintain a consistent meaning for in its two contexts: for a in container: assert a in container# this should ALWAYS be true This shows that is is essential in the interpretation of in. If you loop over elements in a container, then by definition those exact elements are IN the container. If we break this, it will lead to hard to find errors and language inconsistencies. The identity implies equality rule isn't just an optimization, it is a deep assumption that pervades the language implementation. Lots of logic relies on it to maintain invariants. It looks like the 3.0 changes are fighting this state of affairs. IMO, those changes are fighting an uphill battle and will introduce more oddities than they eliminate. -- nosy: +rhettinger versions: +Python 3.0 -Python 2.4, Python 2.5, Python 2.6, Python 2.7 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4297] Add error_log attribute to optparse.OptionParser
Changes by Raghuram Devarakonda [EMAIL PROTECTED]: -- nosy: +draghuram ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4297 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Mark Dickinson [EMAIL PROTECTED] added the comment: Here's a patch incorporating Christian's tests, the missing lines from PyObject_RichCompareBool, and some additional tests to check that [x] == [x] and the like remain True even when x is a NaN. Oh, and a Misc/NEWS entry. With this patch, all tests pass (debug and non-debug 32-bit builds) on OS X 10.5/Intel. I think we should get the okay from Guido before committing this. Maybe he remembers why he deleted these lines in the first place. :-) -- assignee: - gvanrossum Added file: http://bugs.python.org/file11989/issue4296.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Christian Heimes [EMAIL PROTECTED] added the comment: Oh h... Raymond, you are so right! I was too tired to think of all implications related to the different semantic in 3.0, especially the for in / is in invariant. I'm including Guido and Barry into the discussion. This topic needs some attention from the gods of old. :) -- nosy: +barry, gvanrossum priority: normal - release blocker ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4301] incorrect and inconsistent logging in multiprocessing
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- assignee: - jnoller nosy: +jnoller ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4301 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4300] error in multiprocessing logging docs
Benjamin Peterson [EMAIL PROTECTED] added the comment: Thanks for the report! Fixed in r67189. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Christian Heimes [EMAIL PROTECTED] added the comment: The tests are passing on Ubuntu Linux 64bit, too. Good work everybody! -- assignee: gvanrossum - barry stage: test needed - patch review ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3944] faster long multiplication
Mark Dickinson [EMAIL PROTECTED] added the comment: See issue 4258 for a patch that combines 30-bit digits with this multiplication optimization. The code is quite different from the patch posted here, but the basic idea is the same. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3944 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Mark Dickinson [EMAIL PROTECTED] added the comment:
With the lines Raymond mentions restored, all tests (including the extra
tests Christian's posted here) pass for me, and I also get:
a = [float('nan')]
a == a
True
Incidentally, it looks as though the PyObject_RichCompareBool lines were
removed in r51533.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4296
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3705] py3k fails under Windows if -c or -m is given a non-ascii value
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Raising to release blocker, just to trigger another review... -- priority: critical - release blocker ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3705 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3705] py3k fails under Windows if -c or -m is given a non-ascii value
Benjamin Peterson [EMAIL PROTECTED] added the comment: Go ahead. -- keywords: -needs review ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3705 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1675] Race condition in os.makedirs
Zooko O'Whielacronx [EMAIL PROTECTED] added the comment: Here's the version of this that I've been using for almost a decade now: http://allmydata.org/trac/pyutil/browser/pyutil/pyutil/fileutil.py?rev=127#L241 Actually I used to have a bigger version that could optionally require certain things of the mode of the directory, but it turned out that I wasn't going to need it. def make_dirs(dirname, mode=0777): An idempotent version of os.makedirs(). If the dir already exists, do nothing and return without raising an exception. If this call creates the dir, return without raising an exception. If there is an error that prevents creation or if the directory gets deleted after make_dirs() creates it and before make_dirs() checks that it exists, raise an exception. tx = None try: os.makedirs(dirname, mode) except OSError, x: tx = x if not os.path.isdir(dirname): if tx: raise tx raise exceptions.IOError, unknown error prevented creation of directory, or deleted the directory immediately after creation: %s % dirname # careful not to construct an IOError with a 2-tuple, as that has a special meaning... -- nosy: +zooko ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1675 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3439] create a numbits() method for int and long types
Mark Dickinson [EMAIL PROTECTED] added the comment: The latest patch from Victor looks good. A few comments: (1) the number of bits should be computed first directly using C arithmetic, and only recomputed using PyLong arithmetic if the C computations overflow. For one thing, overflow is going to be very rare in practice; for another, in the sort of applications that use .numbits(), speed of numbits() is often critical. (2) Just as a matter of style, I think if (x == NULL) is preferable to if (!x). At any rate, the former style is much more common in Python source. (3) the reference counting all looks good. (4) I quite like the idea of having numbits be a property rather than a method---might still be worth considering? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3439 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3705] py3k fails under Windows if -c or -m is given a non-ascii value
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Fixed as r67190. Thanks for the review. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3705 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1328851] pclose raises spurious exception on win32
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: The subprocess module does return the correct exit code. It should be used instead. -- nosy: +amaury.forgeotdarc resolution: - wont fix status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1328851 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1685] linecache .updatecache fails on utf8 encoded files
Changes by Amaury Forgeot d'Arc [EMAIL PROTECTED]: ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1685 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3439] create a numbits() method for int and long types
Fredrik Johansson [EMAIL PROTECTED] added the comment: In stdtypes.rst, x.numbits should be listed in the table under Bit-string Operations on Integer Types and not in the table of operations supported by all numeric types. (1) the number of bits should be computed first directly using C arithmetic, and only recomputed using PyLong arithmetic if the C computations overflow. +1 (4) I quite like the idea of having numbits be a property rather than a method---might still be worth considering? I'm not against. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3439 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3439] create a numbits() method for int and long types
STINNER Victor [EMAIL PROTECTED] added the comment:
[Mark Dickinson]
(1) the number of bits should be computed first directly using ...
_PyLong_NumBits() : done. But the result type is always long.
(2) Just as a matter of style, I think if (x == NULL) is preferable
done
(4) I quite like the idea of having numbits be a property rather than a
method---might still be worth considering?
I agree, so in the new patch, numbits is now a property.
[Fredrik Johansson]
In stdtypes.rst, x.numbits should be listed in the table under
Bit-string Operations on Integer Types
done
--
10
x=1023L; x.numbits
10L
x=2**(2**10); n=x.numbits; n, n.numbits
(1025L, 11L)
Added file: http://bugs.python.org/file11990/numbits-4.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3439
___Index: Objects/intobject.c
===
--- Objects/intobject.c (révision 67177)
+++ Objects/intobject.c (copie de travail)
@@ -1138,6 +1138,27 @@
return NULL;
}
+static PyObject *
+int_numbits(PyIntObject *v)
+{
+ unsigned long n;
+ long result = 0;
+
+ if (v-ob_ival 0) {
+ /* if LONG_MIN == -LONG_MAX-1 (true on most platforms) then
+ ANSI C says that the result of -ival is undefined when ival
+ == LONG_MIN. Hence the following workaround. */
+ n = (unsigned long)(-1 - v-ob_ival) + 1;
+ } else {
+ n = (unsigned long)v-ob_ival;
+ }
+ while (n) {
+ ++result;
+ n = 1;
+ }
+ return PyInt_FromLong(result);
+}
+
#if 0
static PyObject *
int_is_finite(PyObject *v)
@@ -1161,6 +1182,10 @@
};
static PyGetSetDef int_getset[] = {
+ {numbits,
+(getter)int_numbits, (setter)NULL,
+Returns the number of binary digits in self.,
+NULL},
{real,
(getter)int_int, (setter)NULL,
the real part of a complex number,
Index: Objects/longobject.c
===
--- Objects/longobject.c(révision 67177)
+++ Objects/longobject.c(copie de travail)
@@ -3451,6 +3451,64 @@
return PyInt_FromSsize_t(res);
}
+static PyObject *
+long_numbits(PyLongObject *v)
+{
+ PyLongObject *result, *x, *y;
+ Py_ssize_t ndigits, msd_bits;
+ digit msd;
+ size_t nbits;
+
+ assert(v != NULL);
+ assert(PyLong_Check(v));
+
+ nbits = _PyLong_NumBits((PyObject*)v);
+ if (nbits != (size_t)-1 || !PyErr_Occurred())
+ return PyLong_FromSize_t(nbits);
+
+ ndigits = ABS(Py_SIZE(v));
+ assert(ndigits == 0 || v-ob_digit[ndigits - 1] != 0);
+
+ if (ndigits == 0)
+ return PyLong_FromLong(0);
+
+ msd = v-ob_digit[ndigits - 1];
+ msd_bits = 0;
+ do {
+ ++msd_bits;
+ msd = 1;
+ } while (msd);
+
+ result = (PyLongObject *)PyLong_FromLong(ndigits - 1);
+ if (result == NULL)
+ return NULL;
+ x = (PyLongObject *)PyLong_FromLong(PyLong_SHIFT);
+ if (x == NULL)
+ goto error;
+ y = (PyLongObject *)long_mul(result, x);
+ Py_DECREF(x);
+ if (y == NULL)
+ goto error;
+ Py_DECREF(result);
+ result = y;
+
+ x = (PyLongObject *)PyLong_FromLong(msd_bits);
+ if (x == NULL)
+ goto error;
+ y = (PyLongObject *)long_add(result, x);
+ Py_DECREF(x);
+ if (y == NULL)
+ goto error;
+ Py_DECREF(result);
+ result = y;
+
+ return (PyObject *)result;
+
+error:
+ Py_DECREF(result);
+ return NULL;
+}
+
#if 0
static PyObject *
long_is_finite(PyObject *v)
@@ -3476,6 +3534,10 @@
};
static PyGetSetDef long_getset[] = {
+{numbits,
+ (getter)long_numbits, (setter)NULL,
+ returns the number of binary digits in self.,
+ NULL},
{real,
(getter)long_long, (setter)NULL,
the real part of a complex number,
Index: Lib/test/test_int.py
===
--- Lib/test/test_int.py(révision 67177)
+++ Lib/test/test_int.py(copie de travail)
@@ -240,6 +240,21 @@
self.assertEqual(int('2br45qc', 35), 4294967297L)
self.assertEqual(int('1z141z5', 36), 4294967297L)
+def test_numbits(self):
+self.assertEqual((0).numbits(), 0)
+self.assertEqual((1).numbits(), 1)
+self.assertEqual((-1).numbits(), 1)
+self.assertEqual((2).numbits(), 2)
+self.assertEqual((-2).numbits(), 2)
+for i in [2, 3, 15, 16, 17, 31, 32, 33, 63, 64]:
+a = 2**i
+self.assertEqual((a-1).numbits(), i)
+self.assertEqual((1-a).numbits(), i)
+self.assertEqual((a).numbits(), i+1)
+
[issue3100] weakref subclass segfault
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: This was fixed 4 months ago with r64309 (trunk, 2.6) and r64310 (2.5). -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3100 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4296] Python assumes identity implies equivalence; contradicts NaN
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Mark, the patch looks good. Thanks. Before committing, please add one
other test that verifies the relationship between in in membership
tests and in in a for-loop:
for constructor in list, tuple, dict.fromkeys, set, collections.deque:
container = constructor([float('nan'), 1, None, 'abc'])
for elem in container :
self.assert_(elem in container)
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4296
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1471243] Visual Studio 2005 CRT error handler
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Already implemented, since r47223. -- nosy: +amaury.forgeotdarc resolution: - out of date status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1471243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2971] test_zipfile64 fails
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Fixed with r67194. Note that the test is now always skipped: too big! -- nosy: +amaury.forgeotdarc resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2971 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4079] new urllib2.Request 'timeout' attribute needs to have a default
Senthil [EMAIL PROTECTED] added the comment: http://bugs.python.org/issue4079 -- nosy: +orsenthil ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4079 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
