[issue4294] Macros for PyLong: sign, number of digits, fits in an int
New submission from STINNER Victor [EMAIL PROTECTED]:
It's hard to read Objects/longobject.c because the code depends to
much on the implementation. I wrote macros to simplify the code:
- PyLong_SIGN(x)
- PyLong_EQUALS_ZERO(x)
- PyLong_FITS_INT(x)
- PyLong_GET_INT(x)
- PyLong_NDIGITS(x)
Macros are declared in Include/longintrepr.h to be able to use them
outside longobject.c. Eg. I used it in Modules/mathmodule.c.
The patch also contains extra changes:
- create sdigit type (used by PyLong_GET_INT(x))
- use memcpy() in _PyLong_Copy()
- use stwodigits in long_mul()
- replace many Py_SIZE() hacks by my macros (eg. see long_hash)
Using my patch, it will be easier to change long integer
implementation, like:
- Use 30-bit digits instead of 15-bit digits (issue #4258)
- Use GMP for PyLong (issue #1814)
Example of changes:
i = Py_SIZE(v);
x = 0;
if (i 0) {
PyErr_SetString(PyExc_OverflowError,
can't convert negative value to unsigned
int);
return (unsigned long) -1;
}
switch (i) {
case 0: return 0;
case 1: return v-ob_digit[0];
}
while (--i = 0) {
...
is replaced by:
if (PyLong_SIGN(v) 0) {
PyErr_SetString(PyExc_OverflowError,
can't convert negative value to unsigned
int);
return (unsigned long) -1;
}
if (PyLong_FITS_INT(v))
return (unsigned long) PyLong_GET_INT(v);
x = 0;
i = PyLong_NDIGITS(v);
while (--i = 0) {
...
--
files: pylong_macros.patch
keywords: patch
messages: 75694
nosy: haypo
severity: normal
status: open
title: Macros for PyLong: sign, number of digits, fits in an int
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file11975/pylong_macros.patch
___
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
[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.
Mark Dickinson [EMAIL PROTECTED] added the comment: Here's a minor update to the patch, that does some extra cleanup: - don't include longintrepr.h in Objects/abstract.c or Objects/boolobject.c --- it's not needed. - fix several places in longobject.c where int should have been size_t or Py_ssize_t - remove some unnecessary forward declarations in longobject.c. - fix PyLong_FromLong for small negative integers At some point I'll try to separate the pure bugfixes (missing casts, int vs Py_ssize_t, etc.) from the 15-bit to 30-bit conversion. Added file: http://bugs.python.org/file11976/30bit_longdigit4.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4258 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4282] (Python3) The profile module deesn't understand the character set definition
Changes by STINNER Victor [EMAIL PROTECTED]: -- nosy: +brett.cannon ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4282 ___ ___ 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
Mark Dickinson [EMAIL PROTECTED] added the comment: Another thought: macros that are going to be used elsewhere in Python (like the way you're using PyLong_SIGN in mathmodule.c) would probably be better off in longobject.h. The fewer places there are that have to include longintrepr.h, the easier it is to mess with the internal representation. It's quite tempting to 'fix' _PyLong_AsScaledDouble to return e as the number of bits, rather than the number of digits; then mathmodule.c wouldn't have to include longintrepr.h at all. (And if marshal.c were also changed, to read and write integers as byte strings, we wouldn't need longintrepr.h anywhere any more!) ___ 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
[issue4294] Macros for PyLong: sign, number of digits, fits in an int
STINNER Victor [EMAIL PROTECTED] added the comment: Second patch to optimize some PyLong operations: - Write special code for small (a, b) of long_true_div(), long_bitwise(), and l_divmod() (used by long_div(), long_mod() and long_divmod(), and long_pow()) - PyLong_FromLong(): don't go to the while() for small *negative* integers TODO: Write special code for small integers of long_rshift() and long_lshift() Added file: http://bugs.python.org/file11977/pylong_optimize.patch ___ 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
[issue4294] Macros for PyLong: sign, number of digits, fits in an int
STINNER Victor [EMAIL PROTECTED] added the comment: What's the purpose of your sdigit? The type sdigit should be able to store a signed digit, so a number in [-(2^15-1); 2^15-1]. short may be enough, but I think that the CPU prefers (CPU is faster with) an int because it doesn't have to truncate the MSB (eg. 32 bits (u)int = 16 bits (u)short). I also used int because Python was already using int (right?) would probably be better off in longobject.h Right. It's quite tempting to 'fix' _PyLong_AsScaledDouble to return e as the number of bits, rather than the number of digits Good idea. But instead of writing a patch of 100.000 lines, I prefer to start with a small patch and then add new patches to improve it. It allows to apply only some patches but not all. Is _PyLong_AsScaledDouble() used by another module than mathmodule.c? marshal.c Same: it's better to write a separated patch. -- I opened a new issue because the GMP and 30-bits patchs are too big and it's not easy to review/commit them. The idea is to do small changes to allow bigger changes later. ___ 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
[issue4293] Thread Safe Py_AddPendingCall
Changes by Kristján Valur Jónsson [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file11974/pendingalls.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4293 ___ ___ 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
Mark Dickinson [EMAIL PROTECTED] added the comment: Same: it's better to write a separated patch. Agreed. Unfortunately, I think all of this is going to have to wait for Python 3.0 to be released before we can consider committing anything. The first step is to commit the pure bugfixes (missing casts, etc.). I suppose we *could* do this for 2.6.1/2.7 now, but it seems safer to make all the changes in the 2.x and 3.x branches simultaneously. By the way, I think we can also get rid of wdigit---it can be safely replaced by digit everywhere, as far as I can tell. ___ 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
[issue4293] Thread Safe Py_AddPendingCall
New submission from Kristján Valur Jónsson [EMAIL PROTECTED]: At CCP We have started using the Py_AddPendingCall() mechanism to signal python about a completed IO operation. However, we noticed that the existing mechanism was hoplelessly un- thread safe. This is bad, since on Windows at least, it is very convenient to have such callbacks happen on an arbitrary thread from the system's thread pool. I submit a thread-safe implementation instead to be used if WITH_THREAD is defined. This allows Py_AddPendingCall() to be called from any thread, from any context, even from a PendingCall callback itself. -- components: Interpreter Core files: pendingalls.patch keywords: needs review, patch, patch messages: 75691 nosy: krisvale priority: normal severity: normal status: open title: Thread Safe Py_AddPendingCall type: crash versions: Python 2.7 Added file: http://bugs.python.org/file11974/pendingalls.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4293 ___ ___ 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
STINNER Victor [EMAIL PROTECTED] added the comment: @marketdickinson: As you proposed, here is a patch for _PyLong_AsScaledDouble(): stores directly the number of bits in an unsigned int instead of the number of digits. Added file: http://bugs.python.org/file11979/pylong_asscaleddouble.patch ___ 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
[issue4293] Thread Safe Py_AddPendingCall
Kristján Valur Jónsson [EMAIL PROTECTED] added the comment: Good point. I'll make a test using ctypes and _testcapimodule.c to try to make it as non-platform-specific as possible. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4293 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4292] 2to3 fails to convert from something import (a, b, c)
Ondrej Certik [EMAIL PROTECTED] added the comment: Author: STINNER Victor (haypo): You would like to replace from mptypes import ... by from .mptypes import Is it really a bug? Python is unable to guess if mptypes, functions or settings are global modules or relative modules. Why don't you patch your original code since Python 2.5 also supports this syntax? Documentation: http://www.python.org/doc/2.5.2/ref/import.html http://docs.python.org/reference/simple_stmts.html#the-import-statement ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4292 ___ ___ 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
Christian Heimes [EMAIL PROTECTED] added the comment: I like the idea, Victor -- nosy: +christian.heimes ___ 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
[issue4294] Macros for PyLong: sign, number of digits, fits in an int
Changes by Martin v. Löwis [EMAIL PROTECTED]: -- versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0 ___ 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
[issue4292] 2to3 fails to convert from something import (a, b, c)
STINNER Victor [EMAIL PROTECTED] added the comment: Ooops, I replied to the wrong issue (#4292) :-p My test was wrong: yes, 2to3 needs a patch. I wrote one (with no test yet). -- nosy: +haypo Added file: http://bugs.python.org/file11973/2to3_fix_import.py ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4292 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4282] exec(unicode): invalid charset when #coding:xxx spec is used
Changes by STINNER Victor [EMAIL PROTECTED]: -- title: (Python3) The profile module deesn't understand the character set definition - exec(unicode): invalid charset when #coding:xxx spec is used ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4282 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4290] 2to3 fails with sympy
STINNER Victor [EMAIL PROTECTED] added the comment: You would like to replace from mptypes import ... by from .mptypes import Is it really a bug? Python is unable to guess if mptypes, functions or settings are global modules or relative modules. Why don't you patch your original code since Python 2.5 also supports this syntax? Documentation: http://www.python.org/doc/2.5.2/ref/import.html http://docs.python.org/reference/simple_stmts.html#the-import-statement -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4292] 2to3 fails to convert from something import (a, b, c)
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- assignee: - benjamin.peterson nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4292 ___ ___ 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
Changes by STINNER Victor [EMAIL PROTECTED]: -- nosy: +gregory.p.smith, marketdickinson ___ 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
[issue4290] 2to3 fails with sympy
Ondrej Certik [EMAIL PROTECTED] added the comment: Hi Victor, thanks for the comments. I copied them to the issue 4292 where they belong and replied there. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4292] 2to3 fails to convert from something import (a, b, c)
Ondrej Certik [EMAIL PROTECTED] added the comment: You would like to replace from mptypes import ... by from .mptypes import Yes, exactly, see the patch where I did that. Is it really a bug? Python is unable to guess if mptypes, functions or settings are global modules or relative modules. I think it is a bug, because 2to3 correctly fixed all the other import statements, like from something import a, b, c, but failed with from something import (a, b, c). Why don't you patch your original code since Python 2.5 also supports this syntax? Because we need to support python2.4, a lot of people still use it. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4292 ___ ___ 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
Mark Dickinson [EMAIL PROTECTED] added the comment: Interesting. Incidentally, I'm already using sdigit for the signed version of digit--- this seems to fit with the current digit/twodigits/stwodigits typedefs. What's the purpose of your sdigit? Do you really want it to be type 'int'? ___ 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
[issue3720] segfault in for loop with evil iterator
Changes by STINNER Victor [EMAIL PROTECTED]: -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4293] Thread Safe Py_AddPendingCall
Christian Heimes [EMAIL PROTECTED] added the comment: Your patch sounds like a useful addition. However I can comment on the details because I haven't dealt with Py_AddPendingCall() yet. Documentation updates and a unit test (Modules/_testcapimodule.c), that shows the bug and verifies your patch, are welcome, too. -- keywords: -needs review nosy: +christian.heimes stage: - patch review versions: +Python 3.1 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4293 ___ ___ 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
STINNER Victor [EMAIL PROTECTED] added the comment: Other optimization for long_compare(), long_lshift() and long_rshift(). Note: with all my patches, Python is a little bit faster (but not slower, which is already a good thing ;-)). Added file: http://bugs.python.org/file11980/pylong_shift.patch ___ 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
[issue4279] Module 'parser' fails to build
Andy [EMAIL PROTECTED] added the comment: Martin: Looking at it I agree with you 100% - the patch is too complicated for what it is intending to resolve. It simply does not need another accessor function to muddy the waters when making the symbol public as done in #4288 resolves the issue. My personal preference is to try to hide such data structures - but that doesn't always mean its the correct thing to do :-) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4279 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4244] ihooks incompatible with absolute_import feature
Stefan Behnel [EMAIL PROTECTED] added the comment: This is an (extended) duplicate of issue4152. -- nosy: +scoder ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4290] 2to3 fails with sympy
Benjamin Peterson [EMAIL PROTECTED] added the comment: Second metaclass problem fixed in r67178. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4292] 2to3 fails to convert from something import (a, b, c)
Benjamin Peterson [EMAIL PROTECTED] added the comment: Fixed in r67179. Ondrej, thanks for running 2to3 over sympy and finding all these tasty bugs! -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4292 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4292] 2to3 fails to convert from something import (a, b, c)
Ondrej Certik [EMAIL PROTECTED] added the comment: Benjamin, thanks for the fantastic work! I discovered more bugs, but this time I reported to the py3000 list, as I need more feedback on it. But it seems you'll get another tasty bug for the 2to3, among other things. :) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4292 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4290] 2to3 fails with sympy
Ondrej Certik [EMAIL PROTECTED] added the comment: I can confirm this is now fixed. Thanks very much! ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4290 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4295] closing stdout in a child process on cygwin means that process doesn't receive bytes from stdin anymore. I think.
Zooko O'Whielacronx [EMAIL PROTECTED] added the comment: I opened a ticket on the cygwin issue tracker: http://sourceware.org/bugzilla/show_bug.cgi?id=7017 # closing stdout in a child python process means that process doesn't receive bytes from stdin anymore. I think. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4295 ___ ___ 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
Mark Dickinson [EMAIL PROTECTED] added the comment: There are so many things going on here it's getting difficult to keep track of them all! Not only Victor's stuff, but also Mario's patches for faster multiplication, and for subquadratic division. And it might be interesting to experiment with subquadratic int - str conversion as well. I'm wondering whether it would be worth starting a new py3k_long_optimization branch, so that we can get some of the obvious stuff in and start experimenting properly with the rest. Christian, you're the expert on this: any thoughts? Is it possible to set up a new svn branch so that it's easy to merge from the py3k branch, or is svn merging only really possible from the trunk? I'm happy to set things up and take care of doing regular merges, if you can give me some pointers. (If not, maybe it's time for me to learn how to use git/hg/bzr. I've used darcs quite a bit before, so the concepts aren't totally alien to me, but I haven't found time to learn other systems yet.) ___ 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
[issue4294] Macros for PyLong: sign, number of digits, fits in an int
STINNER Victor [EMAIL PROTECTED] added the comment: I'm unable to use pystone nor pybench to compare all integers patches. So I wrote my own tool: bench_int.py. Don't use to compare different computers or Python versions, it's just useful to test if a patch is faster or slower. Example (still the 64 bits [EMAIL PROTECTED] GHz): --- original : 896.5 ms + macros: 891.0 ms (+0.6%) ++ optimize : 884.3 ms (+1.4%) +++ shift : 880.8 ms (+1.7%) GMP : 700.9 ms (+22%) 30 bits : 659.9 ms (+26%) --- Result: my optimizations are useless, whereas mark's patch (#4258) is 26% faster! My GMP patch is only 22% faster (and so slower than the 30 bits patch). The GMP hack would only be useful for huge value whereas my benchmark tool use mostly small values (the biggest is near 2**200). I use it with sync ./python -OO bench_int.py, run the command 2 or 3 times, and keep the smallest value. Added file: http://bugs.python.org/file11981/bench_int.py ___ 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
[issue4296] Python assumes identity implies equivalence; contradicts NaN
New submission from Michael B Curtis [EMAIL PROTECTED]:
Found in Python 2.4; not sure what other versions may be affected.
I noticed a contradiction with regards to equivalence when experimenting
with NaN, which has the special property that it is itself, but it
doesn't == itself:
a = float('nan')
a is a
True
a == a
False
b = [float('nan')]
b is b
True
b == b
True
I am not at all familiar with Python internals, but the issue appears to
be in PyObject_RichCompareBool of python/trunk/Objects/object.c
This method Guarantees that identity implies equality. However, this
doesn't Gaurantee this fact, but instead Assumes it, because it is
not something that is always True. NaN is identical to itself, but not
equivalent to itself.
At a minimum, the contradiction introduced by this assumption should be
documented. However, it may be possible to do better, by fixing it.
The assumption appears to be made that identity should imply
equivalence, for the common case. Would it therefore be possible to,
instead of having objects such as lists perform this optimization and
make this assumption, instead have the base object types implement this
assumption. That is, for regular objects, when we evaluate equivalence,
we return True if the objects are identical. Then, the optimization can
be removed from objects such as list, so that when they check the
equivalence of each object, the optimization is performed there. NaN
can then override the default behavior, so that it always returns False
in equivalence comparisons.
--
components: Interpreter Core
messages: 75716
nosy: mikecurtis
severity: normal
status: open
title: Python assumes identity implies equivalence; contradicts NaN
type: behavior
versions: Python 2.4
___
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: Interesting, Python 3.0 behaves differently than Python 2.x. Nice catch! :) Python 3.0rc2 (r30rc2:67177, Nov 10 2008, 12:12:09) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 Type help, copyright, credits or license for more information. nan = float(nan) nan is nan True nan == nan False lst = [nan] lst is lst True lst == lst False Python 2.6 (r26:66714, Oct 2 2008, 16:17:49) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type help, copyright, credits or license for more information. nan = float(nan) lst = [nan] lst == lst True lst is lst True -- nosy: +christian.heimes, marketdickinson priority: - normal stage: - test needed versions: +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
[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.
Changes by STINNER Victor [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file11947/30bit_longdigit3.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4258 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.
STINNER Victor [EMAIL PROTECTED] added the comment: Using 30bit_longdigit4.patch, I get this error: Objects/longobject.c:700: erreur: SIZE_T_MAX undeclared (first use in this function). You might use the type Py_ssize_t with PY_SSIZE_T_MAX. I used INT_MAX to compile the code. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4258 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3944] faster long multiplication
Changes by STINNER Victor [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file11567/longobject_diff ___ 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
[issue3944] faster long multiplication
Changes by STINNER Victor [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file11595/longobject1.diff ___ 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
[issue4294] Macros for PyLong: sign, number of digits, fits in an int
STINNER Victor [EMAIL PROTECTED] added the comment: More numbers! -- 64 bits CPU --- original: 885.0 ms fast long: 746.8 ms (+16%) -- issue #3944 -- +16% only with an optimized multiplicaton, great job Pernici :-) -- 32 bits CPU --- original: 1564.3 ms 30 bits: 1497.3 ms (+4%) fast long: 1591.7 ms (-2%) GMP: 1564.4 ms (=) -- It looks like the operation 32 bits x 32 bits is slower on a 32 bits CPU, the gain is small (only +4%). fast long and a little bit slower, and GMP patch doesn't change anything. -- nosy: +pernici ___ 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
[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.
STINNER Victor [EMAIL PROTECTED] added the comment: I like the idea of sys.int_info, but I would prefer a base attribute than bits_per_digit. A base different than 2^n might be used (eg. a base like 10^n for fast conversion from/to string). ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4258 ___ ___ 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]: -- keywords: +needs review stage: - patch review ___ 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
[issue4208] Make multiprocessing compatible with Python 2.4 and 2.5
STINNER Victor [EMAIL PROTECTED] added the comment: See http://code.google.com/p/python-multiprocessing/ project. -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4208 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2494] Can't round-trip datetimes-timestamps prior to 1970 on Windows
STINNER Victor [EMAIL PROTECTED] added the comment: If you doesn't care to the time zone (UTC), use: datetime.datetime(1970, 1, 1) + datetime.timedelta(seconds=-86400) datetime.datetime(1969, 12, 31, 0, 0) This code is portable on Windows, Linux but also works with IronPython: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7269 -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2494 ___ ___ 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
STINNER Victor [EMAIL PROTECTED] added the comment: See also issue2736 ___ 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
[issue1083] Confusing error message when dividing timedelta using /
STINNER Victor [EMAIL PROTECTED] added the comment: The current behaviour is consistent with the integer divison: 21 // 10 2 timedelta(microseconds=20) // 10 datetime.timedelta(0, 0, 2) Whereas int/int gives float: 21 / 10 2.1001 timedelta(microseconds=20) / 1 ... TypeError: unsupported operand type(s) for /: ... Now in the real world, it's hard to understand that the operator // should be used instead of /. So timedelta()/int might be an alias to timedelta()//int. -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1083 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2173] Python fails silently on bad locale
STINNER Victor [EMAIL PROTECTED] added the comment: Can you retry with Python 3.0rc2? -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2173 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2736] datetime needs and epoch method
STINNER Victor [EMAIL PROTECTED] added the comment: See also issue1673409 -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2736 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777412] Python's strftime dislikes years before 1900
STINNER Victor [EMAIL PROTECTED] added the comment: The patch doesn't work on Python3 because Python3 changes time.strftime() for year 1900: if time.accept2dyear is not False (or not set), raise an error; otherwise convert 0..68 = 2000..2068, 69..99 = 1968..1999, or raise an error. -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1777412 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1726687] Bug found in datetime for Epoch time = -1
STINNER Victor [EMAIL PROTECTED] added the comment: The patch is correct. I tried to use errno, but errno is unchanged on error. Here is a new patch with regression tests. -- nosy: +haypo versions: +Python 2.7, Python 3.1 Added file: http://bugs.python.org/file11982/mktime_fix_and_tests.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1726687 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3173] external strftime for Python?
STINNER Victor [EMAIL PROTECTED] added the comment: The issue #1777412 has a working patch (for Python 2.6) which allows year 1900 in time.strftime() and datetime.datetime.strftime(). -- nosy: +haypo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3173 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1545463] New-style classes fail to cleanup attributes
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
amaury What if PyGC_Collect() is called just before?
That would work. With the following patch:
===
--- Python/import.c (revision 67183)
+++ Python/import.c (working copy)
@@ -498,7 +498,10 @@
PyDict_SetItem(modules, key, Py_None);
}
}
-
+ /* Collect garbage remaining after deleting the
+ modules. Mostly reference cycles created by new style
+ classes. */
+ PyGC_Collect();
/* Next, delete sys and __builtin__ (in that order) */
value = PyDict_GetItemString(modules, sys);
if (value != NULL PyModule_Check(value)) {
$ ./python.exe x.py
creating X('new')
creating X('old')
deleting X('old')
deleting X('new')
--
keywords: +patch
Added file: http://bugs.python.org/file11983/gc-import.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1545463
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1545463] New-style classes fail to cleanup attributes
Changes by Alexander Belopolsky [EMAIL PROTECTED]: -- versions: +Python 2.5.3, Python 2.6, Python 2.7 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1545463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
