[issue2719] Backport next()
Raymond Hettinger [EMAIL PROTECTED] added the comment: ISTM, the only value added by next(g) is that it replaces g.next() with a more conventional spelling, g.__next__(). Since 2.6 still has g.next (),I don't see how this backport adds value. It does however create a second way to do it that will be confusing to some remaining in the 2.x world. I think we should avoid double spellings in 2.6 except in cases where the 2-to-3 converter would need help. -- nosy: +rhettinger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2719 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2719] Backport next()
Georg Brandl [EMAIL PROTECTED] added the comment: IMO having next() in 2.6 helps since if you use it consistently you don't have to care about calling .next() or .__next__(). Also, I don't see how this is different from having e.g. reduce() and functools.reduce() in 2.6. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2719 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2723] Truncate __len__() at sys.maxsize
Raymond Hettinger [EMAIL PROTECTED] added the comment: Wouldn't it be better to raise OverflowError or somesuch? -- nosy: +rhettinger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2723 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2719] Backport next()
Raymond Hettinger [EMAIL PROTECTED] added the comment: The problem is with the if you use it consistently premise. That will not hold in an environment with legacy code, multiple programmers, lots of code in ASPN recipes and published materials, and third-party modules. A patch like this dooms Py2.6 programmers to seeing both of these forms intermixed throughout the code base. This is *not* a win. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2719 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 * 2 5 is a prime number 5 is a prime number 5 is a prime number 6 = 2 * 3 7 is a prime number 7 is a prime number 7 is a prime number 7 is a prime number 7 is a prime number 8 = 2 * 4 9 is a prime number 9 = 3 * 3 Can this be corrected in the tutorial as it can be confusing for a python newbie! Thanks! -- assignee: georg.brandl components: Documentation messages: 65996 nosy: georg.brandl, sandeepsabnani severity: normal status: open title: Error in Python tutorial (http://docs.python.org/tut/node6.html) versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2724 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 is precisely the point of this paragraph. -- nosy: +amaury.forgeotdarc resolution: - invalid status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2724 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2632] performance problem in socket._fileobject.read
Changes by Matthias Klose [EMAIL PROTECTED]: -- nosy: +doko __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2632 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue2724 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2717] tempfile.mkstempf
Changes by Giampaolo Rodola' [EMAIL PROTECTED]: -- nosy: +giampaolo.rodola __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2717 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 attached patch will display the error message as was seemingly intended. This probably affects earlier versions (including python-trunk), but I haven't tested. -- components: Build files: fix-asdl-errors.patch keywords: patch messages: 65999 nosy: thomas.lee severity: normal status: open title: Handle ASDLSyntaxErrors gracefully type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file10144/fix-asdl-errors.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2725 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2722] os.getcwd fails for long path names on linux
Changes by Giampaolo Rodola' [EMAIL PROTECTED]: -- nosy: +giampaolo.rodola __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2722 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 PROTECTED] http://bugs.python.org/issue2719 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2721] unittest.makeSuite undocumented and obsolete - but what to use instead?
Changes by Giampaolo Rodola' [EMAIL PROTECTED]: -- nosy: +giampaolo.rodola __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2721 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 idea is that len(..) is not supposed to raise an exception on sizeable objects. Here is a quote from another message: __len__ will always be problematic when there are more values than can be counted in a signed C long; maybe we should do what the Java collections package does: for once, Java chooses practicality over purity, and simply states that if the length doesn't fit, the largest number that does fit is returned (i.e. for us that would be sys.maxsize in 3.0, sys.maxint in 2.x). -- Guido van Rossum, 2008-04-30 http://mail.python.org/pipermail/python-3000/2008-April/013340.html I suspect, however, that part of Java's motivation for this behavior is that exceptions need to be declared and declaring the length method as throwing OverflowError would make many programmers very unhappy. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2723 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 docstring to describe the constructor arguments so
if the constructor argspec
is being shown, I would expect the description of it to be included below.
Result of svn diff sphinx/ext/autodoc.py:
Index: sphinx/ext/autodoc.py
===
--- sphinx/ext/autodoc.py (revision 62582)
+++ sphinx/ext/autodoc.py (working copy)
@@ -154,6 +154,13 @@
result.append(indent + '.. %s:: %s%s' % (what, qualname, args),
'autodoc')
result.append('', 'autodoc')
+# added by abhik (4/29/08)
+if what == 'class':
+initdoc = inspect.getdoc(getattr(todoc, '__init__'))
+if initdoc:
+docstring = docstring if docstring else ''
+docstring += \n + indent + initdoc
+
# the module directive doesn't like content
if what != 'module':
indent += ' '
I don't know how other people would expect autodoc to work so maybe this
behavior could be controlled by
a config param?
--
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 66002
nosy: abhik, georg.brandl
severity: normal
status: open
title: Autodoc's autoclass directive should include constructor docstring
type: behavior
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2726
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue2258 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 issue. -- nosy: +belopolsky __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2719 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 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.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2719
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 designed to return NULL without setting an exception. See e.g. listiter_next(). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2719 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 (def != NULL) {
Line 1093: PyErr_Clear();
I would only call this if PyErr_Occurred() returns true.
--
resolution: - accepted
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2719
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 SystemError. Wrong; the iternext slot is designed to return NULL without setting an exception. See e.g. listiter_next(). I did not know that. Thanks for the explanation. In this case, wouldn't it be cleaner to call PyIter_Next which is documented to return NULL with no exception? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2719 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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_iternext An optional pointer to a function that returns the next item in an iterator, or raises StopIteration when the iterator is exhausted. http://docs.python.org/dev/c-api/typeobj.html#tp_iternext It looks like documentation needs to be updated, but wouldn't it be odd to specify that setting StopIteration exception is optional? It's probably more logical to intercept StopIteration in slot_tp_iternext rather than at every place where tp_iternext is called. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2719 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-in sequence type no exception objects have to be created. In particular the for-loop code would just discard the StopIteration instance again. The requirement that the exception is *optional* is so that if you're calling a Python iterator that *does* create the exception, the exception object (with whatever data the creator might have attached to it) doesn't get lost (or worse, have to be recreated). Calling PyIter_Next() here instead of inlining it would not be advantageous; it would just slow things down since we'd have to make a redundant call to PyErr_Occurred() to distinguish the StopIteration case from other errors. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2719 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1971 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue2692 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2538] memoryview of bytes is not readonly
Changes by Thomas Heller [EMAIL PROTECTED]: -- nosy: +theller __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2538 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 [EMAIL PROTECTED] http://bugs.python.org/issue2723 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 v. Löwis [EMAIL PROTECTED] wrote: Martin v. Löwis [EMAIL PROTECTED] added the comment: Check whether the TCL_DIR or TK_DIR environment variables are set. If so, unset them. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2714 __ Added file: http://bugs.python.org/file10145/unnamed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2714 __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.brbrYou can close the ticket now.brbrThanks,brbrGregbr brdiv class=gmail_quoteOn Tue, Apr 29, 2008 at 2:47 PM, Martin v. Löwis lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; wrote:brblockquote class=gmail_quote style=border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex; div class=Ih2E3dbr Martin v. Löwis lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt; added the comment:br br /divCheck whether the TCL_DIR or TK_DIR environment variables are set. Ifbr so, unset them.br divdiv/divdiv class=Wj3C7cbr __br Tracker lt;a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/agt;br lt;a href=http://bugs.python.org/issue2714; target=_blankhttp://bugs.python.org/issue2714/agt;br __br /div/div/blockquote/divbr ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue2714 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tp_nextiter behavior in the C API documentation type: feature request versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10146/doc-typeobj.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2727 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue2719 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue2727 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2258] Update command line docs for issue 1739468
Georg Brandl [EMAIL PROTECTED] added the comment: Thanks Nick! -- nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2258 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 [EMAIL PROTECTED] http://bugs.python.org/issue2725 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue2722 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 many people crying out. -- nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2716 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1748 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1748 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 understand __future__ statements from __future__ import with_statement print getcontext().prec 28 with localcontext(): ... ctx = getcontext() ... ctx.prec += 2 ... print ctx.prec ... 30 with localcontext(ExtendedContext): ... print getcontext().prec ... 9 print getcontext().prec 28 When it was enabled, it failed. -- components: Library (Lib) messages: 66026 nosy: benjamin.peterson severity: normal status: open title: Failing decimal doctest type: behavior versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2728 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.py): the for statement is traced twice in the first loop iteration, that's because the iterator object is retrieved (GET_ITER) at the beginning of the loop while the next iterator value is fetched (FOR_ITER) at the end of the loop. I don't believe this is very painful. All in all, the whole test suite now passes fine. The performance numbers are the same as before. -- title: speedup loops with better bytecode - speedup for / while / if with better bytecode Added file: http://bugs.python.org/file10147/loops8.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2459 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 severity: normal status: open title: Link error in What's New in Python 2.6 versions: Python 2.6 Added file: http://bugs.python.org/file10148/patch.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2729 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue2729 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 fix is to add a line: setcontext(DefaultContext) just after the ' from __future__ import with_statement' line (around line 480 of decimal.py), to restore the original context. *but*... that doesn't work, because test_decimal.py clobbers DefaultContext (and it shouldn't, in my opinion). I've attached a patch that might fix these problems, and that also enables this doctest. I'm not sure that this patch is necessarily the best way of going about things, though. -- assignee: - facundobatista keywords: +patch nosy: +facundobatista, marketdickinson Added file: http://bugs.python.org/file10149/decimal_localcontext.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2728 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2728] Failing decimal doctest
Changes by Mark Dickinson [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file10149/decimal_localcontext.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2728 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, since that test doesn't use the DefaultContext: it uses its own freshly created context instead. So the patch removes the setting of traps from setUp, and removes tearDown entirely. Added file: http://bugs.python.org/file10150/decimal_localcontext.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2728 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
