[issue1225584] crash in gcmodule.c on python reinitialization

Adam Olsen added the comment: mwh, my threading patch is extensive enough and has enough overlap that I'm not intimidating by fixing this. It's low on my list of priorities though. So far my tendency is to rip out multiple interpreters, as I haven't seen what it wants to accomplish. It's certa

[issue1623] Implement PEP-3141 for Decimal

Jeffrey Yasskin added the comment: Here's a version of the patch that uses _rescale instead of quantize. I don't know enough about how contexts are used to know whether someone might want to know that ceil(Decimal("1e30")) gave a result with more precision than the input. On the other hand, the e

[issue1636] Execfile unable to take arguments beyond 255!

New submission from Jack Atkinson: I found this problem while using PySNMP and trying to load a custom MIB converted to python code. Inside the PySNMP, it uses execfile() to load the python MIBs, and I assume so it won't be put into a separate namespace. On one particular MIB, which I cannot mo

[issue1600] str.format() produces different output on different platforms (Py30a2)

Christian Heimes added the comment: Mark Summerfield wrote: > It seems to me that Python should provide consistent results across > platforms wherever possible and that this is a gratuitous inconsistency > that makes cross-platform testing less convenient than it need be. > > I'll take a look at

[issue1600] str.format() produces different output on different platforms (Py30a2)

Mark Summerfield added the comment: On 2007-12-15, Christian Heimes wrote: > Christian Heimes added the comment: > > Guido is right. On Linux the system's sprintf() family prints %e, %g and > %f with two or three digits while Windows always uses three digits: > > Linux > >>> "%e" % 1e1 > '1.0

[issue1600] str.format() produces different output on different platforms (Py30a2)

Christian Heimes added the comment: Guido is right. On Linux the system's sprintf() family prints %e, %g and %f with two or three digits while Windows always uses three digits: Linux >>> "%e" % 1e1 '1.00e+01' >>> "%e" % 1e10 '1.00e+10' >>> "%e" % 1e100 '1.00e+100' Windows >>> "%e" %

[issue1635] Float patch for inf and nan on Windows (and other platforms)

Christian Heimes added the comment: Update: I've added a platform independent implementation of stricmp and strnicmp (case insensitive compare). It could be useful for other parts of the code as well. Added file: http://bugs.python.org/file8962/trunk_float_inf_nan2.patch __

[issue1632] email cannot be imported

Changes by Georg Brandl: -- status: open -> pending __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue1583] Patch for signal.set_wakeup_fd

Adam Olsen added the comment: The python API has the advantage that you can test for it at runtime, avoiding a compile-time check. I don't know if this is significant though. I don't see the big deal about a C API. All you need to do is call PyImport_ImportModule("signal") and PyObject_CallMet

[issue1583] Patch for signal.set_wakeup_fd

Changes by Gustavo J. A. M. Carneiro: __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/o

[issue1583] Patch for signal.set_wakeup_fd

Gustavo J. A. M. Carneiro added the comment: The patch looks great. But I was wondering if there is any chance to export a C API in addition to the Python one? That is because PyGTK is mostly C, the code that needs this is C, it would be easier to call a C API. -- nosy: +gustavo _

[issue1635] Float patch for inf and nan on Windows (and other platforms)

New submission from Christian Heimes: The patch unifies the creation and representation of "inf", "-inf" and "nan" on all platforms. >>> float("inf") inf >>> float("-inf") -inf >>> float("nan") nan >>> repr(1e300 * 1e300) 'inf' >>> repr(1e300 * 1e300 * 0) 'nan' >>> repr(1e300 * 1e300 * -1) '-in

[issue1634] with Statement SyntaxError generated while following Tutorial

Georg Brandl added the comment: Thanks, fixed in rev 59521. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ __

[issue1634] with Statement SyntaxError generated while following Tutorial

Changes by Christian Heimes: -- assignee: -> georg.brandl nosy: +georg.brandl priority: -> low __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bu