[issue2728] Failing decimal doctest

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Removed the old patch. Here's a better patch, that avoids changing the semantics of the threading tests. As far as I can tell, the setting and resetting of DefaultContext traps in DecimalTest's setUp and tearDown method was pointless, sinc

[issue2728] Failing decimal doctest

Changes by Mark Dickinson <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10149/decimal_localcontext.patch __ Tracker <[EMAIL PROTECTED]> __ _

[issue2728] Failing decimal doctest

Mark Dickinson <[EMAIL PROTECTED]> added the comment: There are a couple of problems here. The direct reason for the failure is that there's an earlier doctest (around line 61 of decimal.py) that sets the precision of the current context to 18 instead of its default value of 28. The obvious

[issue2729] Link error in What's New in Python 2.6

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Thanks. Fixed in r62608. -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __

[issue2729] Link error in What's New in Python 2.6

New submission from Manuel Kaufmann <[EMAIL PROTECTED]>: I found a link error in section "What's New in Python 2.6" to Trac project. I attach the patch file -- assignee: georg.brandl components: Documentation files: patch.diff keywords: patch messages: 66028 nosy: georg.brandl, humitos

[issue2459] speedup for / while / if with better bytecode

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Finally I had to slightly change the lnotab format to have the right tracing semantics: the change is that line number increments are now signed bytes rather than unsigned. Still, there is a small change in tracing behaviour (see test_trace.p

[issue2728] Failing decimal doctest

New submission from Benjamin Peterson <[EMAIL PROTECTED]>: I was removing from __future__ import with_statment in the stdlib when I came across this disabled doctest in decimal.py: # The string below can't be included in the docstring until Python 2.6 # as the doctest module doesn't unde

[issue1748] contextlib.contextmanager does not use functools.wraps

Georg Brandl <[EMAIL PROTECTED]> added the comment: Done in r62605. -- nosy: +georg.brandl resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ __

[issue1748] contextlib.contextmanager does not use functools.wraps

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Can this be fixed? -- nosy: +benjamin.peterson __ Tracker <[EMAIL PROTECTED]> __ ___ Py

[issue2716] Reimplement audioop because of copyright issues

Georg Brandl <[EMAIL PROTECTED]> added the comment: It is, as most "old" standard modules, not actively maintained, but there is always the chance that somebody will fix bugs as they are reported :) Anyway, the algorithms in it won't change, and if you want its removal I predict there will be ma

[issue2722] os.getcwd fails for long path names on linux

Christian Heimes <[EMAIL PROTECTED]> added the comment: It should be MAX_PATH. All path related functions should use MAX_PATH as buffer size, maybe even MAX_PATH+1 -- nosy: +tiran __ Tracker <[EMAIL PROTECTED]> _

[issue2722] os.getcwd fails for long path names on linux

Georg Brandl <[EMAIL PROTECTED]> added the comment: Why isn't the buffer length MAX_PATH anyway? -- nosy: +georg.brandl __ Tracker <[EMAIL PROTECTED]> __ __

[issue2725] Handle ASDLSyntaxErrors gracefully

Georg Brandl <[EMAIL PROTECTED]> added the comment: Some comments: - Since you check for a false mod before calling check(), the check in check() will not be reached. - The error print seems to be already in trunk. -- nosy: +georg.brandl __ Tracker <[EMAI

[issue2258] Update command line docs for issue 1739468

Georg Brandl <[EMAIL PROTECTED]> added the comment: Thanks Nick! -- nosy: +georg.brandl __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list m

[issue2727] clarify tp_nextiter behavior in the C API documentation

Georg Brandl <[EMAIL PROTECTED]> added the comment: Changed a bit and committed in r62602. -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> __

[issue2719] Backport next()

Georg Brandl <[EMAIL PROTECTED]> added the comment: Updated and committed as r62599. Also fixed your nits in the original 3k version in r62598. -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> ___

[issue2727] clarify tp_nextiter behavior in the C API documentation

New submission from Alexander Belopolsky <[EMAIL PROTECTED]>: See discussion in issue2719 for details. -- assignee: georg.brandl components: Documentation files: doc-typeobj.diff keywords: patch messages: 66016 nosy: belopolsky, georg.brandl severity: normal status: open title: clarify t

[issue2714] Unable to start IDLE on Windows Server 2003 x64 Edition w/ SP2

Facundo Batista <[EMAIL PROTECTED]> added the comment: Closed as by OP indication. -- resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ _

[issue2714] Unable to start IDLE on Windows Server 2003 x64 Edition w/ SP2

Gregory Dai <[EMAIL PROTECTED]> added the comment: All I needed was starting a new shell/DOS prompt. In the old one, there were residual environment variables having to do with TCL set up by Ruby installation. You can close the ticket now. Thanks, Greg On Tue, Apr 29, 2008 at 2:47 PM, Martin

[issue2723] Truncate __len__() at sys.maxsize

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Gasp, having len() return something else than the true container size sounds horrible. At least raising OverflowError makes it clear that something wrong is going on... -- nosy: +pitrou __ Tracker <[EM

[issue2538] memoryview of bytes is not readonly

Changes by Thomas Heller <[EMAIL PROTECTED]>: -- nosy: +theller __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe:

[issue2692] bytes object wrongly exposes writeable buffer interface

Thomas Heller <[EMAIL PROTECTED]> added the comment: Duplicate of issue #2538. -- resolution: -> duplicate status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1971] ctypes exposing the pep 3118 buffer interface

Thomas Heller <[EMAIL PROTECTED]> added the comment: Instead of waiting for review I've committed this as rev 62597. -- assignee: -> theller resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __

[issue2719] Backport next()

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Feel free to submit a patch to fix the docs. Changing the API is not an option -- it's been like this since the tp_iternext slot was added, and it's been designed like this for a reason: so that in the common case of iterating over a built-

[issue2719] Backport next()

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Wed, Apr 30, 2008 at 12:41 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > the iternext slot is designed to return NULL without setting an > exception. This is not what the documentation says: """ iternextfunc PyTypeObject.tp_ite

[issue2719] Backport next()

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Wed, Apr 30, 2008 at 12:41 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Guido van Rossum <[EMAIL PROTECTED]> added the comment: > > > .. builtin_next() should return > > NULL without an exception set and thus trigger a Syst

[issue2719] Backport next()

Guido van Rossum <[EMAIL PROTECTED]> added the comment: +1 on this. I have a few nits about the code: Line 1083: "%.200s object is not an iterator", it->ob_type->tp_name); Line is too long. Line 1088: if (res == NULL) { How about if (res != NULL) return res; ? Line 1089: if (def) { if

[issue2719] Backport next()

Guido van Rossum <[EMAIL PROTECTED]> added the comment: > I would think tp_iternext failing to set an exception should not be > translated into stop iteration. Instead, builtin_next() should return > NULL without an exception set and thus trigger a SystemError. Wrong; the iternext slot is des

[issue2719] Backport next()

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: One more question: What is the rationale for + res = (*it->ob_type->tp_iternext)(it); + if (res == NULL) { .. + PyErr_SetNone(PyExc_StopIteration); + return NULL; ? I would think

[issue2719] Backport next()

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: I thought new code is supposed to use Py_TYPE macro instead of ->ob_type: + "%.200s object is not an iterator", it->ob_type- >tp_name); .. + res = (*it->ob_type->tp_iternext)(it); Py3k branch has the same is

[issue2258] Update command line docs for issue 1739468

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Updated in rev 62593. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __

[issue2726] Autodoc's autoclass directive should include constructor docstring

New submission from Abhik Shah <[EMAIL PROTECTED]>: The autoclass directive adds the class constructor's argspec to the header and shows the class docstring below it but doesn't add the constructor's docstring. I usually use the class docstring to describe the class and the constructor's doc

[issue2723] Truncate __len__() at sys.maxsize

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment: On Wed, Apr 30, 2008 at 2:32 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Wouldn't it be better to raise OverflowError or somesuch? Thats what the current code does. I don't know what Guido's full rationale is, but I guess the

[issue2719] Backport next()

Guido van Rossum <[EMAIL PROTECTED]> added the comment: I think it's important to make this available in 2.6; it will let people writing 3.0-oriented code in 2.6 (as several developers are planning to do) do the right thing for this syntax. __ Tracker <[EMAIL PROT

[issue2725] Handle ASDLSyntaxErrors gracefully

New submission from Thomas Lee <[EMAIL PROTECTED]>: The current code in Parser/asdl.py doesn't handle syntax errors very well. A minor problem to be sure, since the net result is the same (i.e. build fails), but the error message being displayed is entirely unhelpful to the developer. The attach

[issue2717] tempfile.mkstempf

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>: -- nosy: +giampaolo.rodola __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list

[issue2721] unittest.makeSuite undocumented and "obsolete" - but what to use instead?

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>: -- nosy: +giampaolo.rodola __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list

[issue2722] os.getcwd fails for long path names on linux

Changes by Giampaolo Rodola' <[EMAIL PROTECTED]>: -- nosy: +giampaolo.rodola __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list

[issue2724] Error in Python tutorial (http://docs.python.org/tut/node6.html)

Sandeep Sabnani <[EMAIL PROTECTED]> added the comment: Oh yes! Thanks for clearing my doubt and apologies for the silly error. __ Tracker <[EMAIL PROTECTED]> __

[issue2724] Error in Python tutorial (http://docs.python.org/tut/node6.html)

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: No, the example is correct, and gives the expected output. >From the output you show, I suppose that you indented the "else:" clause incorrectly: it should align with the "for" loop, not the "if" statement. The "for...else.." construct

[issue2632] performance problem in socket._fileobject.read

Changes by Matthias Klose <[EMAIL PROTECTED]>: -- nosy: +doko __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe:

[issue2724] Error in Python tutorial (http://docs.python.org/tut/node6.html)

New submission from Sandeep Sabnani <[EMAIL PROTECTED]>: Section 4.4 on page http://docs.python.org/tut/node6.html has a for loop which uses the range function. However, the displayed output of that loop is not correct. I ran the same code and got the output as follows: 3 is a prime number 4 = 2