[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]> ___ __

[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 (wor

[issue1777412] Python's strftime dislikes years before 1900

STINNER Victor <[EMAIL PROTECTED]> added the comment: See also issue #3173. ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list ma

[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]>

[issue1777412] Python's strftime dislikes years before 1900

Changes by STINNER Victor <[EMAIL PROTECTED]>: ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue1777412] Python's strftime dislikes years before 1900

STINNER Victor <[EMAIL PROTECTED]> added the comment: See also Issue1777412. ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list m

[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_tes

[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.

[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]> ___ _

[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 ... Ty

[issue1673409] datetime module missing some important methods

STINNER Victor <[EMAIL PROTECTED]> added the comment: See also issue2736 ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list maili

[issue2736] datetime needs and "epoch" method

STINNER Victor <[EMAIL PROTECTED]> added the comment: See also issue1673409 -- nosy: +haypo ___ Python tracker <[EMAIL PROTECTED]> ___ _

[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.

[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]> ___ _

[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]> ___ ___

[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

[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

[issue3944] faster long multiplication

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11595/longobject1.diff ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3944] faster long multiplication

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11567/longobject_diff ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[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. __

[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]> ___

[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 informat

[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 =

[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 (sti

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

Christian Heimes <[EMAIL PROTECTED]> added the comment: It's probably easier to wait a couple of days until 3.0.0 is out. I don't know how the new branches will look like. By the way your work fits nicely in my plans to work on optimizations for 3.1. Go, Victor, go! ___

[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

[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. __

[issue4295] closing stdout in a child process on cygwin means that process doesn't receive bytes from stdin anymore. I think.

New submission from Zooko O'Whielacronx <[EMAIL PROTECTED]>: When someone runs "bin/trial --reactor=select twisted.internet.test.test_process.ProcessTestsBuilder_PollReactor.test_ childConnectionLost" on cygwin, using the cygwin version of Python, either manually (which I've done on two cygwin

[issue4294] Macros for PyLong: sign, number of digits, fits in an int

STINNER Victor <[EMAIL PROTECTED]> added the comment: More benchmark with py3k trunk on a Quad [EMAIL PROTECTED] GHz (64 bits): ./python Lib/test/pystone.py 25 (maximum value on 5 runs): - original: 58685.4 pystones/second - patched: 61274.5 pystones/second Don't trust pystones, results a

[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]> ___ __

[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. :) __

[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]>

[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]> __

[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]> ___ _

[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

[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]> ___ ___

[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]> ___

[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]> ___ __

[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

[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 (m

[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]> ___ _

[issue4293] Thread Safe Py_AddPendingCall

Kristján Valur Jónsson <[EMAIL PROTECTED]> added the comment: Okay, i add a new patch that includes tests. I am unsure where I should add documentation for the Py_AddPendingCall () function. Any suggestions? Added file: http://bugs.python.org/file11978/pendingalls.patch ___

[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 t

[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 t

[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

[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'? __

[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

[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]> ___ ___

[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)

[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]> __

[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 pat

[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

[issue3720] segfault in for loop with evil iterator

Changes by STINNER Victor <[EMAIL PROTECTED]>: -- nosy: +haypo ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing l

[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 ___

[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]>

[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

[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. Wh

[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]>

[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]> ___ ___ Python-bugs-list ma

[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

[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.