[issue1779871] Make python build with gcc-4.2 on OS X 10.4.9
Jeffrey Yasskin added the comment: In http://gcc.gnu.org/ml/gcc/2005-12/msg00368.html, Mike Stump <[EMAIL PROTECTED]> said "This flag [-no-cpp-precomp] should be removed from the compile, it hasn't been needed in a long while (since gcc-3.1)." which was released in 2002. I'm happy to remove -mno-fused-madd if you say it's unnecessary. Ronald, do you mean "Removing that option [-Wno-long-double] seems to be harmless"? Keeping it harms compiles with non-apple gcc's, but I could add it to a block like -mno-fused-madd. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1779871> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1450807] Python build fails for gcc 4.x from Gnu
Changes by Jeffrey Yasskin: -- nosy: +jyasskin _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1450807> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1779871] Make python build with gcc-4.2 on OS X 10.4.9
Jeffrey Yasskin added the comment: I'm not going to get to this for about a week, but I'll test the patch then. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1779871> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1200] Allow array.array to be parsed by the t# format unit.
New submission from Jeffrey Yasskin:
This changes PyArg_ParseTuple()'s "t#" to request a PyBUF_SIMPLE buffer
like all of the other buffer-using format units instead of
PyBUF_CHARACTER. Objects with multi-byte units wind up
byte-order-dependent. Alternately, it might make sense to have
array.array('b') and array.array('B') accept the PyBUF_CHARACTER flag.
I haven't actually tested this patch on a big-endian machine.
--
components: Interpreter Core
files: let_t_format_take_array.patch
messages: 56126
nosy: jyasskin
severity: normal
status: open
title: Allow array.array to be parsed by the t# format unit.
type: behavior
versions: Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1200>
__
let_t_format_take_array.patch
Description: Binary data
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1184] test fixes for immutable bytes change
Jeffrey Yasskin added the comment: To be precise, this change makes bytes immutable but does not give it a __hash__ method or change the values its iterator returns. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1184> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1676820] Add a PeriodicTimer to threading
Jeffrey Yasskin added the comment: Java's Timer class tends to be discouraged these days in favor of ScheduledExecutorService.scheduleAtFixedRate and .scheduleWithFixedDelay (http://download.oracle.com/javase/7/docs/api/java/util/concurrent/ScheduledExecutorService.html). Could you say why you modeled this interface off of java.util.Timer instead of ScheduledExecutor? See http://www.python.org/dev/peps/pep-3148/ for the basis of executors in Python. I'm skeptical of having a PeriodicTimer that embeds a fixed-delay timing. Both fixed-rate and fixed-delay are useful for different things, and given the ambiguity we probably shouldn't give in to the temptation to guess. I'm skeptical of having a new thread per periodic task. It's a little more work to multiplex tasks onto shared threads, and maybe that work isn't worth it for now, but I think the interface should allow future implementations to multiplex their tasks. -- ___ Python tracker <http://bugs.python.org/issue1676820> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10260] Add a threading.Condition.wait_for() method
Jeffrey Yasskin added the comment: * This method will confuse some people who will think that cond.wait(pred) will wake up when pred becomes true regardless of whether they call cond.notifyAll(). You should warn them about this in the documentation. (This confusion happens inside Google, despite our documentation, but the method's worth having even though not everyone will read the docs.) You should also mention that 'predicate' runs with the Condition acquired. Then +1 whether or not you do anything in response to the below comments. * There's a small risk of confusion with C++0x's wait_for method, which behaves like the current Condition.wait (waiting for a timeout). They used "wait_for" because they also have a "wait_until" that waits until a deadline. I don't think this potential confusion is a big deal. * This expands the interface needed to duck-type as a Condition. Maybe you could also add a threading.wait_for(Condition, predicate, timeout) that implements the same thing using just the Condition's .wait() method? I'm not certain that'll be the best name as a threading method, but I don't have a better proposal. -- ___ Python tracker <http://bugs.python.org/issue10260> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10260] Add a threading.Condition.wait_for() method
Jeffrey Yasskin added the comment: On Tue, Nov 2, 2010 at 4:29 AM, Antoine Pitrou wrote: >> I spent some time thinking of a name. I tried wait_predicate and >> predicate_wait, but wait_for seemed natural. Any other ideas? >> How about wait_until_true? > > wait_for is ok IMO. Agreed. >> My original method had this as a free function, but I moved it into >> the Condition because I could see no other kind of primitive that >> would use it. I agree that it is unfortunate to pull what is >> essentially a utility function into the Condition variable, so I am >> leaning towards keeping it a module function. > > I'm not sure I see the point. It's an operation on a Condition variable, > so it's natural to have it as a Condition method. A module function > would feel rather weird. Yeah, it should primarily be used as a Condition method. I was suggesting implementing that Condition method in terms of a threading function, which would also help other people trying to, say, mock Condition objects. But that's not a big deal, and I could be wrong about whether it's useful at all. As I said earlier, I'm happy with this patch either way. (Note that Condition.wait_for is helpful to people mocking Condition anyway, since the number of calls is much more fixed than the calls to Condition.wait.) -- ___ Python tracker <http://bugs.python.org/issue10260> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3197] Documentation for fractions module needs work
Jeffrey Yasskin <[EMAIL PROTECTED]> added the comment: > [sign] integer '.' [fraction] | [sign] ['.'] fraction Shouldn't make the second '.' optional or this will match plain numerators too. Otherwise, looks good. Thanks for fixing this! ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3197> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2325] isinstance(anything, MetaclassThatDefinesInstancecheck) raises instead of returning False
Jeffrey Yasskin <[EMAIL PROTECTED]> added the comment: I don't think so. It wouldn't be a bug if I wrote: >>> class Meta(type): ... def __instancecheck__(self, other): ... return True >>> isinstance(3, Meta) ... False but it is a bug that the isinstance call raises an exception. If recent builds no longer raise an exception, then the bug should be closed. You guys also seem to have missed that the examples in PEP 3119 in fact define __instancecheck__ as a normal method on a metaclass (which makes it a classmethod on classes derived from that metaclass) instead of as a classmethod on a metaclass. -- resolution: invalid -> status: closed -> open ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2325> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3056] Simplify the Integral ABC
Jeffrey Yasskin <[EMAIL PROTECTED]> added the comment: Yeah, I'll take a look. Feel free to bug me if I haven't gotten to it in a couple more days. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3056> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8032] Add gdb7 hooks to make it easier to debug Python
Changes by Jeffrey Yasskin : -- nosy: +jyasskin ___ Python tracker <http://bugs.python.org/issue8032> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8032] Add gdb7 hooks to make it easier to debug Python
Jeffrey Yasskin added the comment: http://sourceware.org/gdb/current/onlinedocs/gdb/Auto_002dloading.html says "If this file exists and is readable, gdb will evaluate it as a Python script." So maybe it doesn't need to be executable? -- ___ Python tracker <http://bugs.python.org/issue8032> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7316] Add a timeout functionality to common locking operations
Jeffrey Yasskin added the comment: Thanks, looks good. Sorry for the delay. -- resolution: -> accepted ___ Python tracker <http://bugs.python.org/issue7316> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8553] 2to3 breaks relative imports
New submission from Jeffrey Yasskin : 2to3, at least the version in the python-2 tree, currently turns from . import refactor into from .. import refactor which breaks the transformation of 2to3 itself. The attached patch fixes this and tests it. Once someone's looked this over, where should I commit it? I'm not sure where 2to3 actually lives anymore. -- components: Library (Lib) files: 2to3_fix.patch keywords: needs review, patch, patch messages: 104392 nosy: jyasskin priority: normal severity: normal stage: patch review status: open title: 2to3 breaks relative imports type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file17114/2to3_fix.patch ___ Python tracker <http://bugs.python.org/issue8553> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8553] 2to3 breaks relative imports
Jeffrey Yasskin added the comment: Thanks! Committed as r80573. -- keywords: -needs review stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue8553> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8566] 2to3 should run under python 2.5
New submission from Jeffrey Yasskin : Sorry for being all curmudgeonly, but we're using 2to3 in the benchmark suite at http://hg.python.org/benchmarks/, and, since many of the non-CPython implementations are still only 2.5-compatible, the version there needs to run under python 2.5. At the same time, we'd like to be able to use the benchmark version of 2to3 to convert benchmarks to python-3, so we can benchmark changes to CPython's py3k branch. To do that, it'd be nice to be able to import the official 2to3 repository to pick up bug fixes. Therefore, it would be nice for the official repository to run under 2.5. Here's a patch accomplishing that. It passes its test suite under both 2.5 and 2.6, and can convert itself, and then the converted version can reconvert the original version and get the same result. You can also review the patch at http://codereview.appspot.com/996043. -- assignee: benjamin.peterson components: 2to3 (2.x to 3.0 conversion tool) files: 2to3_support_2.5.patch keywords: needs review, patch, patch messages: 104475 nosy: benjamin.peterson, jyasskin priority: normal severity: normal stage: patch review status: open title: 2to3 should run under python 2.5 versions: Python 2.5, Python 2.7 Added file: http://bugs.python.org/file17125/2to3_support_2.5.patch ___ Python tracker <http://bugs.python.org/issue8566> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8566] 2to3 should run under python 2.5
Jeffrey Yasskin added the comment: In what way will my patch break test_parser on Windows? I preserved the behavior of re-opening the file in text mode after determining the encoding. Do I need to add 'U' to open()'s mode string? -- ___ Python tracker <http://bugs.python.org/issue8566> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8566] 2to3 should run under python 2.5
Jeffrey Yasskin added the comment: Thanks. Committed as r80668. May I update http://python.org/dev/peps/pep-0291/ to reflect that 2to3 should continue working on python-2.5? -- ___ Python tracker <http://bugs.python.org/issue8566> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8566] 2to3 should run under python 2.5
Jeffrey Yasskin added the comment: Done. -- keywords: -needs review stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue8566> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3605] Py_FatalError causes infinite loop
Jeffrey Yasskin added the comment: I have a fix at http://codereview.appspot.com/1184043, which makes PyErr_Occurred() return NULL when there is no thread. I'll commit it tomorrow unless there are comments. -- assignee: -> jyasskin keywords: +needs review nosy: +jyasskin stage: unit test needed -> patch review ___ Python tracker <http://bugs.python.org/issue3605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3605] Py_FatalError causes infinite loop
Jeffrey Yasskin added the comment: Fixed in r81142. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue3605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1623] Implement PEP-3141 for Decimal
New submission from Jeffrey Yasskin: I added __round__, __ceil__, __floor__, and __trunc__ -- components: Library (Lib) files: decimal_3141.patch messages: 58614 nosy: jyasskin severity: normal status: open title: Implement PEP-3141 for Decimal type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file8951/decimal_3141.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1623> __ decimal_3141.patch Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 error .quantize()
throws is clearly the wrong one, so this is at least an improvement.
Added file: http://bugs.python.org/file8963/decimal_3141.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1623>
__
decimal_3141.patch
Description: Binary data
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1623] Implement PEP-3141 for Decimal
Jeffrey Yasskin added the comment:
Re math.{floor,ceil}(float): oops, that's definitely a bug. I'll fix it.
Re backporting: yes, and I believe trunc() should be backported too.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1623>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1656] Make math.{floor,ceil}(float) return ints per PEP 3141
New submission from Jeffrey Yasskin:
See
http://python.org/dev/peps/pep-3141/#changes-to-operations-and-magic-methods
--
components: Library (Lib)
files: floorceil_return_int.patch
messages: 58792
nosy: jyasskin
severity: normal
status: open
title: Make math.{floor,ceil}(float) return ints per PEP 3141
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8990/floorceil_return_int.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1656>
__
floorceil_return_int.patch
Description: Binary data
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1623] Implement PEP-3141 for Decimal
Jeffrey Yasskin added the comment: Are you guys suggesting the backport before or after checking this in to the py3k branch? Either's fine with me. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1623> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1623] Implement PEP-3141 for Decimal
Jeffrey Yasskin added the comment: Right. Will do. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1623> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1689] Backport PEP 3141 to 2.6
Jeffrey Yasskin added the comment: I've committed this as r59671, except that round() returns a float again to make sure we keep compatibility. Let me know if you find anything that needs fixing. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1689> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1656] Make math.{floor,ceil}(float) return ints per PEP 3141
Jeffrey Yasskin added the comment: Submitted as r59747. -- keywords: +py3k status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1656> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1747] isinstance(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False
New submission from Jeffrey Yasskin: Python 2.6a0 (trunk:59791M, Jan 6 2008, 12:22:37) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import abc [30620 refs] >>> class A: ... __metaclass__ = abc.ABCMeta ... [30650 refs] >>> class B: ... pass ... [30659 refs] >>> issubclass(B, A) Traceback (most recent call last): File "", line 1, in File "/Users/jyasskin/src/python/trunk-abc/Lib/abc.py", line 191, in __subclasscheck__ if cls in subclass.__mro__: AttributeError: class B has no attribute '__mro__' [30701 refs] >>> This causes Decimal to break in interesting ways when I make it subclass numbers.Real. test_abc doesn't catch it because it declares __metaclass__=type at the top level. :-( This looks relatively easy to fix, so I'll work on a patch. -- assignee: jyasskin components: Library (Lib) messages: 59412 nosy: gvanrossum, jyasskin severity: normal status: open title: isinstance(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1747> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1623] Implement PEP-3141 for Decimal
Jeffrey Yasskin added the comment: I think this reflects the consensus of http://mail.python.org/pipermail/python-dev/2008-January/075798.html. I haven't yet implemented Context.round() as I suggested at http://mail.python.org/pipermail/python-dev/2008-January/075920.html because there are more details to discuss, and I don't want to sidetrack the discussion about basic PEP 3141 support. The test currently fails due to issue 1747. I'll double-check that it passes once that's fixed. -- dependencies: +isinstance(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False Added file: http://bugs.python.org/file9080/decimal-3141.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1623> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1747] issubclass(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False
Jeffrey Yasskin added the comment: This is certainly not the only way to fix this. Is it the best? -- keywords: +patch title: isinstance(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False -> issubclass(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False Added file: http://bugs.python.org/file9082/subclass_oldstyle.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1747> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1747] issubclass(NotSubclassOfObject, InstanceOfAbcMeta) fails instead of returning False
Jeffrey Yasskin added the comment: Committed as r59809. -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1747> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1623] Implement PEP-3141 for Decimal
Jeffrey Yasskin added the comment: Much smaller now. 3.0 will need an additional patch beyond the "automatic" forward port. -- versions: +Python 2.6 Added file: http://bugs.python.org/file9083/decimal-3141-just-trunc.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1623> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1623] Implement PEP-3141 for Decimal
Jeffrey Yasskin added the comment: _dec_from_triple: Probably, yes. It doesn't seem to have any practical effect, but it's good to be consistent. __lt__, __le__: It doesn't matter whether they're called because they have the same effect as __cmp__. They're only there to implement numbers.Real. Perhaps, though, this is a sign that numbers.Real should require __cmp__ instead in 2.6? Or all of the rich comparisons instead of just the two minimal ones? NaNs: I think the guideline is to keep the current behavior for 2.6, and it's not needed for the 3141 implementation, but if that issue comes to a conclusion before I get the 3.0 implementation submitted, I'm happy to follow it. Performance: cProfile points at abc.__instancecheck__ taking 20% of the total time (1132436 calls). This could be a problem... I'll check how that's changed (on my machine) from head and if I can fix it. Thanks for your detailed reviews, Mark! __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1623> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1623] Implement PEP-3141 for Decimal
Jeffrey Yasskin added the comment: Yes, making Decimal subclass object instead of Real and Inexact makes it as fast as it used to be. ABCMeta.__instancecheck__ is easy to speed up, but after fixing it, we're still about 25% behind. So here'a version that just registers Decimal as a subclass instead of having it inherit. I removed __le__ and __lt__ too, since, without subclassing numbers.Real, nothing requires them to exist, and the behavior's the same. Added file: http://bugs.python.org/file9105/decimal-3141-just-trunc-registered.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1623> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1762] Inheriting from ABC slows Decimal down.
Jeffrey Yasskin added the comment: I've only verified the behavior on 2.6, but I suspect it's true for both. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1762> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1762] Inheriting from ABC slows Decimal down.
New submission from Jeffrey Yasskin: Adding numbers.Real to Decimal's base classes almost doubles the time its its test suite takes to run. A profile revealed that a large fraction of that slowdown was in __instancecheck__, but even after optimizing that, it's still about 25% slower. It looks like the rest of the slowdown is still in other parts of the isinstance() check. It would be nice if inheriting from ABCs didn't slow your class down. -- components: Library (Lib) messages: 59543 nosy: jyasskin, nnorwitz severity: normal status: open title: Inheriting from ABC slows Decimal down. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1762> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment:
Thanks again for the excellent comments.
__init__: good catch.
repr(Rational): The rule for repr is "eval(repr(object)) == object".
Unfortunately, that doesn't decide between the two formats, since both
assume some particular import statements. I picked the one more likely
to be unique, and I assume Decimal picked the shorter one. I can go
either way.
_gcd's sign: It's a happy accident for me. Possibly Sjoerd Mullender
designed it that way. I've added a comment and a test.
__ceil__: I like that implementation better.
2-argument round: Fixed and tested.
equality: Very good point. I've stolen the sandbox code and added
Rational.from_float() using it. I think I also need to make this change
to the comparisons.
hashing: oops, yes these should be hashable. Decimal cheats by comparing
!= to even floats that it's equal to, so I'm going to assume that they
also want Rational(5,2) != Decimal('2.5').
The new patch is against 2.6.
--
keywords: +patch
Added file: http://bugs.python.org/file9114/rational.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1682>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment:
> * Follow the decimal module's lead in assiduously avoiding
> float->rational conversions. Something like Rat.from_float(1.1) is
> likely to produce unexpected results (like locking in an inexact input
> and having an unexpectedly large denominator).
I agree that it's not usually what people ought to use, and I don't
think it's an essential part of the API. It might be a useful starting
point for the approximation methods though. .trim() and .approximate()
in
http://svn.python.org/view/sandbox/trunk/rational/Rational.py?rev=40988&view=auto
and Haskell's approxRational
(http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Data-Ratio.html)
start from rationals instead of floats. On the other hand, it might
make sense to provide explicit methods to approximate from floats
instead of asking people to execute the two-phase process. I'm happy
to give it a different name or drop it entirely.
> * Likewise, follow decimal's lead in avoiding all automatic coercisions
> from floats: Rational(3,10) + 0.3 for example. The two don't mix.
I'm reluctant to remove the fallback to float, unless the consensus is
that it's always a bad idea to support mixed-mode arithmetic (which is
possible: I was surprised by the loss of precision of "10**23/1" while
writing this). Part of the purpose of this class is to demonstrate how
to implement cross-type operations. Note that it is an automatic
coercion _to_ floats, so it doesn't look like you've gotten magic
extra precision.
> * Consider following decimal's lead on having a context that can limit
> the maximum size of a denominator. There are various strategies for
> handling a limit overflow including raising an exception or finding the
> nearest rational upto the max denominator (there are some excellent
> though complex published algorithms for this) or rounding the nearest
> fixed-base (very easy). I'll dig out my HP calculator manuals at some
> point -- they had worked-out a number of challenges with fractional
> arithmetic (including their own version of an Inexact tag).
Good idea, but I'd like to punt that to a later revision if you don't
mind. If we do punt, that'll force the default context to be "infinite
precision" but won't prevent us from adding explicit contexts. Do you
see any problems with that?
> * Consider adding Decimal.from_rational and Rational.from_decimal. I
> believe these are both easy and can be done losslessly.
Decimal.from_rational(Rat(1, 3)) wouldn't be lossless, but
Rational.from_decimal is easier than from_float. Then
Decimal.from_rational() could rely on just numbers.Rational, so it
would be independent of this module. Is that a method you'd want on
Decimal anyway? The question becomes whether we want the rational to
import decimal to implement the typecheck, or just assume that
.as_tuple() does the right thing. These are just as optional as
.from_float() though, so we can also leave them for future
consideration.
> * Automatic coercions to/from Decimal need to respect the active decimal
> context. For example the result of Rational(3,11) +
> Decimal('3.1415926') is context dependent and may not be commutative.
Since I don't have any tests for that, I don't know whether it works.
I suspect it currently returns a float! :) What do you want it to do?
Unfortunately, giving it any special behavior reduces the value of the
class as an example of falling back to floats, but that shouldn't
necessarily stop us from making it do the right thing.
> * When in doubt, keep the API minimal so we don't lock-in design mistakes.
Absolutely!
> * Test the API by taking a few numerical algorithms and seeing how well
> they work with rational inputs (for starters, try
> http://docs.python.org/lib/decimal-recipes.html ).
Good idea. I'll add some of those to the test suite.
> * If you do put in a method that accepts floats, make sure that it can
> accept arguments to control the rational approximation. Ideally, you
> would get something something like this Rational.approximate(math.pi, 6)
> --> 355/113 that could produce the smallest rationalal approximation to
> a given level of accuracy.
Right. My initial plan was to use
Rational.from_float(math.pi).simplest_fraction_within(Rational(1,
10**6)) but I'm not set on that, and, because there are several
choices for the approximation method, I'm skeptical whether it should
go into the initial revision at all.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1682>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment:
If the consensus is that Decimal should not implement Real, I'll reply
to that thread and withdraw the patch.
Raymond, do you want me to add Decimal.__init__(Rational) in this patch
or another issue/thread?
I don't understand the comment about scaling down long integers. It's
already the case that float(Rational(10**23, 10**24 + 7))==0.1.
Mark, I agree that .trim() and/or .approximate() (which I think is the
same as Haskell's approxRational) would be really useful. Do you have
particular reasons to pick .trim? Are those the best names for the
concepts? I'd also really like to be able to link from their docstrings
to a proof that their implementations are correct. Does anyone know of one?
Finally, Decimal("2.5") != Rational(5, 2) because Decimal("2.5") != 2.5
(so it'd make equality even more intransitive) and hash(Decimal("2.5"))
!= hash(2.5) so we couldn't follow the rule about equal objects implying
equal hash codes, which is probably more serious. I don't have a
principled explanation for Decimal's behavior, but given that it's
fixed, I think the behavior of non-integral Rationals is determined too.
On the other hand, I currently have a bug where Rational(3,1) !=
Decimal("3") where the hash code could be consistent. I'll fix that by
the next patch.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1682>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1623] Implement PEP-3141 for Decimal
Jeffrey Yasskin added the comment: The discussion on issue 1682 concluded that Decimal should not implement Real at all. -- resolution: -> rejected status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1623> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment:
_binary_float_to_ratio: Oops, fixed.
Rational() now equals 0, but I'd like to postpone Rational('3/2') until
there's a demonstrated need. I don't think it's as common a use as
int('3'), and there's more than one possible format, so some real world
experience will help (that is, quite possibly not in 2.6/3.0). I'm also
postponing Rational(instance_of_numbers_Rational).
+/-inf and nan are gone, and hash is fixed, at least until the next bug.
:) Good idea about using tuple.
Parentheses in str() help with reading things like
"%s**2"%Rational(3,2), which would otherwise format as "3/2**2". I don't
feel strongly about this.
Equality and the comparisons now work for complex, but their
implementations make me uncomfortable. In particular, two instances of
different Real types may compare unequal to the nearest float, but equal
to each other and have similar but inconsistent problems with <=. I can
trade off between false ==s and false !=s, but I don't see a way to make
everything correct. We could do better by making the intermediate
representation Rational instead of float, but comparisons are inherently
doomed to run up against the fact that equality is uncomputable on the
computable reals, so it's probably not worthwhile to spend too much time
on this.
I've added a test that float(Rational(long('2'*400+'7'),
long('3'*400+'1'))) returns 2.0/3. This works without any explicit
scaling on my part because long.__truediv__ already handles it. If
there's something else I'm doing wrong around here, I'd appreciate a
failing test case.
The open issues I know of are:
* Is it a good idea to have both numbers.Rational and
rational.Rational? Should this class have a different name?
* trim and approximate: Let's postpone them to a separate patch (I do
think at least one is worth including in 2.6+3.0). So that you don't
waste time on them, we already have implementations in the sandbox and
(probably) a good-enough explanation at
http://en.wikipedia.org/wiki/Continued_fraction#Best_rational_approximations.
Thanks for the offer to help out with them. :)
* Should Rational.from_float() exist and with the current name? If
there's any disagreement, I propose to rename it to
Rational._from_float() to discourage use until there's more consensus.
* Rational.from_decimal(): punted to a future patch. I favor this for
2.6+3.0.
* Rational('3/2') (see above)
I think this is close enough to correct to submit and fix up the
remaining problems in subsequent patches. If you agree, I'll do so.
Added file: http://bugs.python.org/file9152/rational.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1682>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment: Thanks! I've added some minimal documentation and construction from other Rationals. The other formats for string parsing center around where whitespace is allowed, and whether you can put parens around the whole fraction. Parens would, of course, go away if str() no longer produces them. So they're not significantly different. I guess my objection to construction from strings is mostly that I'm ambivalent, and especially for a core library, that means no. If there's support from another core developer or two, I'd have no objections. Inexact is saying that one thing could be ==3 and the other ==0, so I think it's correct. Negative zeros are a problem. :) I think the default implementations are still fine, but you're right that classes like Decimal will need to think about it, and the numbers module should mention the issue. It's not related to the Rational implementation though, so in another patch. I've submitted this round as r59974. Onto the next patch! :) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1779871] Make python build with gcc-4.2 on OS X 10.4.9
Jeffrey Yasskin added the comment: Sorry for taking so long to get to this. gcc 4.2.1 still produces the following errors with this patch: gcc -c -fno-strict-aliasing -mno-fused-madd -no-cpp-precomp -g -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/opt/local/include -DPy_BUILD_CORE -o Objects/boolobject.o Objects/boolobject.c gcc: unrecognized option '-no-cpp-precomp' cc1: error: unrecognized command line option "-mno-fused-madd" make: *** [Objects/boolobject.o] Error 1 I see you dropped the test for -mno-fused-madd. Since gcc-4.2 doesn't support it, I meant I didn't mind if you dropped the flag entirely. It looks like -no-cpp-precomp stuck around because it doesn't actually cause the compile to fail, just to produce a warning message. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1779871> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment: Here's a patch that adds construction from strings (Guido favored them) and .from_decimal(), changes __init__ to __new__ to enforce immutability, and removes "rational." from repr and the parens from str. I don't expect this to be contentious, so I'll commit it tomorrow unless I hear objections. Added file: http://bugs.python.org/file9201/rational_tweaks.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment:
After this come the two approximation methods. Both are implemented
using the continued fraction representation of the number:
http://en.wikipedia.org/wiki/Continued_fraction#Best_rational_approximations.
The first, currently named "trim", takes the closest rational whose
denominator is less than a given number. This seems useful for
computations in which you want to sacrifice some accuracy for speed. At
one point in this discussion, Guido suggested that Decimal removed the
need for a method like this, and this type isn't optimized for speed anyway.
The other, currently named "approximate", returns the "simplest"
rational within a certain distance of the real value. This seems useful
for converting from float and displaying results to users, where we
prefer readability over accuracy ("yes, I'll take '1/3' even though it's
farther away than '1234/3690'.").
We could provide 0, 1, or both of them, or an accessor for the continued
fraction representation of the number, which might help with third-party
implementations of both. I've never actually used either of these, so I
can't say which is actually more useful. It's probably a good question
to send to the full python-dev list. Even if we decide against including
them in the class, we might put the implementations into the docs or the
test as a demonstration.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1682>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment: I coulda sworn I looked for is_nan and is_infinite. Oh well, switched to using .is_finite, which is even better and checked in as r60068. Thanks for the pointer. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1965] Move trunc() to math module
Changes by Jeffrey Yasskin: -- resolution: -> accepted __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1965> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1968] Unused number magic methods leaked into Py2.6
Jeffrey Yasskin added the comment: I can't find the __round__, __ceil__, and __floor__ methods in int, long, and float. I left them in Rational on purpose, thinking that there might be a module that provided the new behaviors for 2.6 code, but you're probably right that these should be rolled back until such a module appears. They do have the benefit of demonstrating that it's possible to write a numeric class that does the right thing in both 2.6 and 3.0 without many code changes. (I should check that 2to3 does the right thing on it.) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1968> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1968] Unused number magic methods leaked into Py2.6
Jeffrey Yasskin added the comment: Will do. -- components: +Library (Lib) resolution: -> accepted __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1968> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1968] Unused number magic methods leaked into Py2.6
Jeffrey Yasskin added the comment: Done in r60480. -- resolution: accepted -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1968> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1965] Move trunc() to math module
Jeffrey Yasskin added the comment: Moved in r60486. I tried to improve the docstring too. -- resolution: accepted -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1965> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1965] Move trunc() to math module
Jeffrey Yasskin added the comment: Go ahead and fix the docstring. I don't really understand what was incorrect about the original "returns the integral closest to x between 0 and x", so I'm not confident that I'll come up with something you'll like. -- assignee: jyasskin -> rhettinger __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1965> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1965] Move trunc() to math module
Jeffrey Yasskin added the comment: *sigh* That's the version I put there. Did you read the patch before complaining about it? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1965> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment: Whoops, sorry for taking a while to answer. +0 on adding support for '2.' and '.3', given that they're allowed for float and Decimal. Not +1 because they'll make the regular expression more complicated, and they're not exactly necessary, but if you want to add them, go ahead. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment: I think '1e+100' would constitute feature creep at this point, but thanks for the suggestion, and the improvement in the readability of the regex! __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment: I think Rational should handle all floating types as consistently as possible, whatever their radix or precision. It's unlikely that people will convert from them often anyway, especially from Decimal, so the shorter conversion from Decimal doesn't seem to outweigh the extra complexity in the constructor's behavior. If I turn out to be wrong about this, we can revisit it in 3.1. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2002] Make int() fall back to trunc()
New submission from Jeffrey Yasskin: Per http://mail.python.org/pipermail/python-dev/2008-January/076564.html. -- assignee: jyasskin messages: 62014 nosy: jyasskin priority: high severity: normal status: open title: Make int() fall back to trunc() type: behavior versions: Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2002> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2002] Make int() fall back to trunc()
Jeffrey Yasskin added the comment: Here's a patch to implement the fallback for both int and long. I'm pretty sure that _PyNumber_ConvertIntegralToInt() is in the wrong place. Where would be a better place for it? -- keywords: +patch nosy: +rhettinger Added file: http://bugs.python.org/file9352/int_fall_back_to_trunc.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2002> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2002] Make int() fall back to trunc()
Jeffrey Yasskin added the comment: > There is also part of this patch that touches classobject.c but I'm not > yet sure what the visible effect of that change would be or what the > change was hoping to accomplish. All classic classes take the (m && m->nb_int) branch, so without the change to classobject.c, they'd never hit the fallback to __trunc__. The unfortunate side-effect is that when you call int() or long() on a classic class without the right methods, you get an AttributeError complaining about __trunc__ instead of about __int__. Since long() already mistakenly complained about __int__, I didn't consider this a showstopper, but it should be possible to fix if you want. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2002> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2002] Make int() fall back to trunc()
Jeffrey Yasskin added the comment: Submitted as r60566. -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2002> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment: I figured I'd time the difference before we change the code: $ ./python.exe -m timeit -s 'import rational; r=rational.Rational(3, 1)' 'r.numerator' 100 loops, best of 3: 0.696 usec per loop $ ./python.exe -m timeit -s 'import rational; r=rational.Rational(3, 1)' 'r._numerator' 1000 loops, best of 3: 0.155 usec per loop $ ./python.exe -m timeit -s '(3).numerator' 1000 loops, best of 3: 0.0324 usec per loop $ ./python.exe -m timeit -s '(3L).numerator' 1000 loops, best of 3: 0.0356 usec per loop $ ./python.exe -m timeit -s 'from rational import Rational' 'Rational(3, 1)' 1 loops, best of 3: 80.4 usec per loop $ ./python.exe -m timeit -s 'from rational import Rational; r=Rational(3, 1)' 'isinstance(r, Rational)' 10 loops, best of 3: 10.6 usec per loop So every time we change .numerator to ._numerator we save half a microsecond. If we construct a new Rational from the result, that's totally drowned out by the Rational() call. Even checking whether we're looking at a Rational costs 20 times as much as the difference, although that can probably be optimized. I think this means that we shouldn't bother changing the arithmetic methods since it makes the code more complicated, but changing unary methods, especially ones that don't return Rationals, can't hurt. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment: Mark: Coming from C++, I don't have any intuition on static vs. class methods. It might be strange to write MyRationalSubclass.from_float() and get a Rational back, but it might also be strange to write a subclass with a different constructor and get an error. So go ahead. Guido: It would be a shame to decide that classes shouldn't inherit from ABCs for performance reasons. Issue 1762 tracks the problem, but I haven't paid much attention to it. Let's see if we can fix that before using virtual inheritance for Rational. Special-casing ints in the constructor sounds like a good idea, and we can cache the results of .numerator and .denominator in _add, etc, without having to change the overall logic, which should save 2μs (leaving 1 on the table). It could be useful to declare a private constructor that expects ints that are already in lowest terms, sort of like decimal._dec_from_triple(). __add__ couldn't use it directly, but __abs__ could. I don't think it's too late to rename one of the classes. I'm using "RationalAbc" inside of rational.py to refer to numbers.Rational, which is one reason I was positive on adding a suffix to the ABCs, but renaming this class is fine with me too. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1762] Inheriting from ABC slows Decimal down.
Jeffrey Yasskin added the comment: I measured various implementations of __instancecheck__ using `./python.exe -m timeit -s 'from rational import Rational; r = Rational(3, 2)' '...'` on my 2.33 GHz MacBook, with ... replaced by either isinstance(r, Rational) or isinstance(3, Rational) to measure both the positive and negative cases. The big win comes from avoiding the genexp and the set. Then we win smaller amounts by being more careful about avoiding extra calls to __subclasscheck__ and by inlining the cache checks. # Current code return any(cls.__subclasscheck__(c) for c in set([instance.__class__, type(instance)])) isinstance(3, Rational): 4.65 usec isinstance(r, Rational): 7.47 usec # The best we can do simply in Python return cls.__subclasscheck__(instance.__class__) isinstance(3, Rational): 2.08 usec isinstance(r, Rational): 1.72 usec # Preserve behavior, simply return (cls.__subclasscheck__(instance.__class__) or cls.__subclasscheck__(type(instance))) isinstance(3, Rational): 3.03 usec isinstance(r, Rational): 1.8 usec # Preserve behavior, complexly ic = instance.__class__ if cls.__subclasscheck__(ic): return True t = type(instance) return t is not ic and cls.__subclasscheck__(t) isinstance(3, Rational): 2.38 usec isinstance(r, Rational): 1.86 usec # Inlined for new-style classes subclass = instance.__class__ if subclass in cls._abc_cache: return True type_ = type(instance) if type_ is subclass: if (cls._abc_negative_cache_version == ABCMeta._abc_invalidation_counter and subclass in cls._abc_negative_cache): return False return cls.__subclasscheck__(subclass) return (cls.__subclasscheck__(subclass) or cls.__subclasscheck__(type_)) isinstance(3, Rational): 2.26 usec isinstance(r, Rational): 1.49 usec __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1762> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1762] Inheriting from ABCs makes classes slower.
Jeffrey Yasskin added the comment: Right. Decimal was just the place I noticed the problem first. Now it affects Rational more, but it's really a problem with ABCs in general, not specific concrete classes. -- title: Inheriting from ABC slows Decimal down. -> Inheriting from ABCs makes classes slower. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1762> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Jeffrey Yasskin added the comment: Re convergents: In the interest of minimality, I don't think from_continued_fraction and to_continued_fraction need to stick around. I think the other thread established pretty conclusively that .convergents() is not a particularly good building block for either nearby-fraction method, so I'd let people who want it implement it themselves. Neal Norwitz suggested and I agree that .trim() isn't descriptive enough, so let's follow Raymond's alternative of .limit_denominator(). Would you like to commit your implementation? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1762] Inheriting from ABCs makes classes slower.
Jeffrey Yasskin added the comment: I've committed the inlined option as r60762. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1762> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Jeffrey Yasskin added the comment:
r60785 speeds the benchmark up from 10.536s to 4.910s (on top of
whatever my __instancecheck__ fix did). Here are the remaining
interesting-looking calls:
ncalls tottime percall cumtime percall filename:lineno(function)
...
10.2070.2074.9994.999 {sum}
161.5870.0003.4190.000 fractions.py:58(__new__)
70.1700.0003.2360.000 fractions.py:295(forward)
80.6410.0002.8810.000 fractions.py:322(_add)
90.2020.0001.5560.000 benchmark.py:3()
160.8290.0000.8290.000 fractions.py:17(gcd)
160.4770.0000.7570.000 abc.py:63(__new__)
330.2460.0000.2460.000 abc.py:164(__instancecheck__)
160.2070.0000.2070.000 {method 'get' of
'dictproxy' objects}
1000710.1850.0000.1850.000 {isinstance}
300.1090.0000.1090.000 fractions.py:200(denominator)
240.0730.0000.0730.000 {built-in method __new__
of type object at 0xfeea0}
150.0650.0000.0650.000 fractions.py:196(numerator)
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1682>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1762] Inheriting from ABCs makes classes slower.
Jeffrey Yasskin added the comment: Guido and I discussed this, and the next step seems to be to rewrite _Abstract in C and push it into object. For an idea of how much that'll help, just commenting out _Abstract.__new__ takes the Fraction() constructor from 9.35us to 6.7us on my box, and the C we need (a new flag on the class) should run very quickly. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1762> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Jeffrey Yasskin added the comment: Thanks for writing the __add__ optimization down. I hadn't realized how simple it was. I think both optimizations are worth it. 22% on a rarely used class is worth 24 lines of python, and I think nearly eliminating the overhead of ABCs (which will prevent them from getting a bad performance reputation) is worth some C. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2115] __slots__ make attribute setting 10x slower
New submission from Jeffrey Yasskin: (On a MacBook Pro 2.33 GHz) $ ./python.exe -m timeit -s 'class Foo(object): pass' -s 'f = Foo()' 'f.num = 3' 1000 loops, best of 3: 0.13 usec per loop $ ./python.exe -m timeit -s 'class Foo(object): __slots__ = ["num"]' -s 'f = Foo()' 'f.num = 3' 100 loops, best of 3: 1.24 usec per loop Attribute reading isn't affected: $ ./python.exe -m timeit -s 'class Foo(object): pass' -s 'f = Foo(); f.num = 3' 'g = f.num' 1000 loops, best of 3: 0.107 usec per loop $ ./python.exe -m timeit -s 'class Foo(object): __slots__ = ["num"]' -s 'f = Foo(); f.num = 3' 'g = f.num' 1000 loops, best of 3: 0.101 usec per loop -- components: Interpreter Core messages: 62408 nosy: jyasskin severity: normal status: open title: __slots__ make attribute setting 10x slower type: resource usage versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2115> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1762] Inheriting from ABCs makes classes slower.
Jeffrey Yasskin added the comment: I'd like a second opinion about whether it's a good idea to commit the attached patch, which moves abc._Abstract into object. Its effect is to speed ./python.exe -m timeit -s 'import abc' -s 'class Foo(object): __metaclass__=abc.ABCMeta' 'Foo()' up from 2.5us to 0.201us. For comparison: $ ./python.exe -m timeit -s 'import abc' -s 'class Foo(object): pass' 'Foo()' 1000 loops, best of 3: 0.203 usec per loop $ ./python.exe -m timeit -s 'import abc' -s 'class Foo(object):' -s ' def __new__(cls): return super(Foo, cls).__new__(cls)' 'Foo()' 100 loops, best of 3: 1.18 usec per loop $ ./python.exe -m timeit -s 'import abc' -s 'from decimal import Decimal' 'Decimal()' 10 loops, best of 3: 9.51 usec per loop After this patch, the only slowdown I can find is an extra .5us in isinstance, so I think it'll be time to close this bug. Added file: http://bugs.python.org/file9442/optimize_abc.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1762> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Jeffrey Yasskin added the comment: 1) No worries. Even without inlining the common case of __add__, etc., Fraction is now faster than Decimal for smallish fractions [sum(Fraction(1, i) for i in range(1, 100))], and for large ones [sum(Fraction(1, i) for i in range(1, 1000))] gcd takes so much of the time that I can't see the effects of any of the optimizations I've made. Since I wasn't thinking of this as a high-performance class, I'm taking that as a sign to stop optimizing, but gcd is definitely the function to tackle if anyone wants to keep going. 2) I haven't been following __format__, but adding it to Rational sounds fine to me. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1193577] add server.shutdown() method and daemon arg to SocketServer
Jeffrey Yasskin added the comment: This is getting in my way, so I'll take a look at it. I'm planning to model the shutdown API after http://java.sun.com/javase/6/docs/api/java/util/concurrent/ExecutorService.html. The serve_forever->shutdown interval should probably also be available through a context manager. -- assignee: skip.montanaro -> jyasskin nosy: +jyasskin _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1193577> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1517495] memory leak threading or socketserver module
Jeffrey Yasskin added the comment: It's possible but unlikely that r61011 fixed this. SocketServer creates the reference cycles it fixed, but they tended to get cleaned up by gc.collect(), so it sounds like that wasn't the bug you're seeing here. I haven't had time yet to check, so I'm mentioning it here so the possibility doesn't get lost. -- nosy: +jyasskin _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1517495> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1910] Document that with is slower than try/finally
Changes by Jeffrey Yasskin: -- nosy: +jyasskin __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1910> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2179] with should be as fast as try/finally
New submission from Jeffrey Yasskin: Currently, 'with' costs about .2us over try/finally: $ ./python.exe -m timeit -s 'import thread; lock = thread.allocate_lock()' 'lock.acquire()' 'try: pass' 'finally: lock.release()' 100 loops, best of 3: 0.617 usec per loop $ ./python.exe -m timeit -s 'import thread; lock = thread.allocate_lock()' 'with lock: pass' 100 loops, best of 3: 0.774 usec per loop Since it's doing the same thing (and calling the same C functions to do the lock manipulation), it shouldn't take more time. The bytecodes associated with the two options look like: 2)with lock: 3) pass 2 0 LOAD_GLOBAL 0 (lock) 3 DUP_TOP 4 LOAD_ATTR1 (__exit__) 7 STORE_FAST 0 (_[1]) 10 LOAD_ATTR2 (__enter__) 13 CALL_FUNCTION0 16 POP_TOP 17 SETUP_FINALLY4 (to 24) 3 20 POP_BLOCK 21 LOAD_CONST 0 (None) >> 24 LOAD_FAST0 (_[1]) 27 DELETE_FAST 0 (_[1]) 30 WITH_CLEANUP 31 END_FINALLY 32 LOAD_CONST 0 (None) 35 RETURN_VALUE 6)lock.acquire() 7)try: 8) pass 9)finally: 10) lock.release() 6 0 LOAD_GLOBAL 0 (lock) 3 LOAD_ATTR1 (acquire) 6 CALL_FUNCTION0 9 POP_TOP 7 10 SETUP_FINALLY4 (to 17) 8 13 POP_BLOCK 14 LOAD_CONST 0 (None) 10 >> 17 LOAD_GLOBAL 0 (lock) 20 LOAD_ATTR2 (release) 23 CALL_FUNCTION0 26 POP_TOP 27 END_FINALLY 28 LOAD_CONST 0 (None) 31 RETURN_VALUE The major difference I see is the extra local variable (_[1]) used by with. It looks like the compiler ought to be able to save that on the stack instead, and save 3 opcodes. Neal Norwitz suggested that, if that optimization is impossible, WITH_CLEANUP could be modified to take the variable as a parameter, which would let it absorb the LOAD_FAST and DELETE_FAST instructions. I've added everyone on the previous bug to the nosy list. Sorry if you don't care. :) -- components: Interpreter Core messages: 62951 nosy: amaury.forgeotdarc, benjamin.peterson, jyasskin, nnorwitz, rhettinger, tiran severity: normal status: open title: with should be as fast as try/finally type: feature request versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2179> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1910] Document that with is slower than try/finally
Jeffrey Yasskin added the comment: I've filed issue 2179 to see if it's possible to make with as fast as try/finally. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1910> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2184] Speed up Thread.start()
New submission from Jeffrey Yasskin: Thread.start() used sleep(0.01) to make sure it didn't return before the new thread had started. At least on my MacBook Pro, that wound up sleeping for a full 10ms (probably 1 jiffy). By using an Event instead, we can be absolutely certain that the thread has started, and return more quickly (217us). Before: $ ./python.exe -m timeit -s 'from threading import Thread' 't = Thread(); t.start(); t.join()' 100 loops, best of 3: 10.3 msec per loop $ ./python.exe -m timeit -s 'from threading import Thread; t = Thread()' 't.isAlive()' 100 loops, best of 3: 0.47 usec per loop After: $ ./python.exe -m timeit -s 'from threading import Thread' 't = Thread(); t.start(); t.join()' 1000 loops, best of 3: 217 usec per loop $ ./python.exe -m timeit -s 'from threading import Thread; t = Thread()' 't.isAlive()' 100 loops, best of 3: 0.86 usec per loop To be fair, the 10ms isn't CPU time, and other threads including the spawned one get to run during it. There are also some slightly more complicated ways to get back the .4us in isAlive() if we want. -- components: Library (Lib) files: faster_thread_startup.diff keywords: patch, patch messages: 62963 nosy: jyasskin severity: normal status: open title: Speed up Thread.start() type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9546/faster_thread_startup.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2184> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1762] Inheriting from ABCs makes classes slower.
Jeffrey Yasskin added the comment: Since there were no comments, I submitted the patch as r61098. I think we're done here. :) -- resolution: -> fixed status: open -> closed type: -> behavior versions: +Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1762> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2184] Speed up Thread.start()
Jeffrey Yasskin added the comment: Submitted as r61100. -- assignee: -> jyasskin resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2184> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1540386] SocketServer.ForkingMixIn.collect_children() waits on pid 0
Jeffrey Yasskin added the comment: Mostly fixed in r61106. This should make the buildbots happy, but there is still a corner case in which we waitpid(0) and could confuse other libraries. -- nosy: +jyasskin type: -> behavior versions: +Python 2.6 _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1540386> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1183] race in SocketServer.ForkingMixIn.collect_children
Jeffrey Yasskin added the comment: Hmm. I think the race can only happen if you call collect_children() concurrently from multiple threads or from a signal handler. The waidpid(0) bug (which affected anyone who spawned subprocesses from anything other than ForkingMixIn) is partly fixed by r61106, but I don't intend to make ForkingMixIn thread- or signal-safe. Let me know if this is enough for you. :) -- nosy: +jyasskin resolution: -> fixed status: open -> pending versions: +Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1183> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1183] race in SocketServer.ForkingMixIn.collect_children
Changes by Jeffrey Yasskin: -- status: pending -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1183> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.
Jeffrey Yasskin added the comment: I agree that we're basically done here. I'm back to -1 on inlining the common case for arithmetic (attached here anyway). Simple cases are already pretty fast, and bigger fractions are dominated by gcd time, not function call overhead. Since duplicating the definitions of arithmetic will make it harder to do tricky things that shrink the arguments to gcd(), we shouldn't do it. I was always +0 to __format__, so not doing it is fine with me. Thanks for everyone's help! -- resolution: -> fixed status: open -> closed Added file: http://bugs.python.org/file9570/fraction_inline_arith.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1682> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1193577] add server.shutdown() method and daemon arg to SocketServer
Jeffrey Yasskin added the comment: Polling isn't a great way to handle shutdown, since it wastes CPU time and decreases responsiveness, but it's also easy and my attempt to avoid it isn't getting anywhere, so I'm planning to fix up your patch a bit and commit it. Thanks! I've merged your patch with my conflicting change in the trunk and re-attached it. Two things: 1) This patch may interfere with the existing timeout in await_request. We may be able to re-use that instead of having two select statements. 2) I believe it's important to provide a way to block until the server isn't accepting any more requests and to block until all active requests are finished running. If the active requests depend on other bits of the system, blocking until they're done would help them terminate gracefully. It would also be useful to give users a more proactive way to kill active requests, perhaps by listing the handler objects associated with them (or their PIDs for forking servers). It's surprisingly complicated to avoid race conditions in these implementations, especially without support from the Server object. Added file: http://bugs.python.org/file9579/polling_shutdown.patch _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1193577> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1193577] add server.shutdown() method to SocketServer
Jeffrey Yasskin added the comment: Also, Pedro's argument against a daemon_threads argument to TCPServer convinces me. I think we can add it in ThreadingMixIn.__init__ once this whole hierarchy is switched over to new-style classes. That's already done in 3.0, but I don't know what it would affect in 2.6. If anyone wants to keep pushing it, would you open a new bug? -- title: add server.shutdown() method and daemon arg to SocketServer -> add server.shutdown() method to SocketServer _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1193577> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1012468] Rational.py various bugfixes
Jeffrey Yasskin added the comment: Yep. Removed in r61162. -- resolution: -> out of date status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1012468> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1193577] add server.shutdown() method to SocketServer
Jeffrey Yasskin added the comment: It seems that .await_request() was only added a month ago to fix issue 742598, so it's no great hardship to refactor it again now. Timeouts never worked for .serve_forever() because the try/except in .handle_request() turned their exception into a plain return, which didn't stop .server_forever() from looping. Timeouts also seem to be unnecessary in a situation in which shutdown works. Shutdown can only be called from a separate thread, and when you have more threads you can also do periodic tasks in them. So I've made that explicit: the .serve_forever/shutdown combination doesn't handle timeouts. [This has nothing to do with the fact that it takes three times as much code to handle them. Don't look at the excuse behind the curtain. ;)] This patch needs some more documentation and a NEWS entry before it gets submitted, but I want to check that everyone would be happy with the concept. -- nosy: +akuchling, pilcrow versions: +Python 2.6, Python 3.0 Added file: http://bugs.python.org/file9581/polling_shutdown.patch _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1193577> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1193577] add server.shutdown() method to SocketServer
Jeffrey Yasskin added the comment: I'll submit the attached patch in a couple days unless I get comments. Added file: http://bugs.python.org/file9586/polling_shutdown.patch _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1193577> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2179] with should be as fast as try/finally
Jeffrey Yasskin added the comment: Here's a proof-of-concept patch that keeps the __exit__ method on the stack. It uses ROT_TWO to stuff it under the context object instead of storing it into a temporary. (Thanks Nick for pointing out that problem before I had to waste time on it.) test_with passes, although I need to update several more things and maybe fix a refleak. The patch changes the compilation of: def with_(l): with l: pass from 4 0 LOAD_FAST0 (l) 3 DUP_TOP 4 LOAD_ATTR0 (__exit__) 7 STORE_FAST 1 (_[1]) 10 LOAD_ATTR1 (__enter__) 13 CALL_FUNCTION0 16 POP_TOP 17 SETUP_FINALLY4 (to 24) 5 20 POP_BLOCK 21 LOAD_CONST 0 (None) >> 24 LOAD_FAST1 (_[1]) 27 DELETE_FAST 1 (_[1]) 30 WITH_CLEANUP 31 END_FINALLY 32 LOAD_CONST 0 (None) 35 RETURN_VALUE to 4 0 LOAD_FAST0 (l) 3 DUP_TOP 4 LOAD_ATTR0 (__exit__) 7 ROT_TWO 8 LOAD_ATTR1 (__enter__) 11 CALL_FUNCTION0 14 POP_TOP 15 SETUP_FINALLY4 (to 22) 5 18 POP_BLOCK 19 LOAD_CONST 0 (None) >> 22 WITH_CLEANUP 23 END_FINALLY 24 LOAD_CONST 0 (None) 27 RETURN_VALUE And speeds it up from: $ ./python.exe -m timeit -s 'import thread; lock = thread.allocate_lock()' 'with lock: pass' 100 loops, best of 3: 0.832 usec per loop to: $ ./python.exe -m timeit -s 'import thread; lock = thread.allocate_lock()' 'with lock: pass' 100 loops, best of 3: 0.762 usec per loop That's only half of the way to parity with try/finally: $ ./python.exe -m timeit -s 'import thread; lock = thread.allocate_lock()' 'lock.acquire()' 'try: pass' 'finally: lock.release()' 100 loops, best of 3: 0.638 usec per loop What's strange is that calling __enter__ and __exit__ in a try/finally block brings the speed back to the faster 'with' speed, even though they call the same C functions: $ ./python.exe -m timeit -s 'import thread; lock = thread.allocate_lock()' 'lock.__enter__()' 'try: pass' 'finally: lock.__exit__()' 100 loops, best of 3: 0.754 usec per loop Any ideas? -- keywords: +patch Added file: http://bugs.python.org/file9589/faster_with.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2179> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2179] with should be as fast as try/finally
Jeffrey Yasskin added the comment: Now with documentation, a working test_compile, and one less refleak. Added file: http://bugs.python.org/file9590/faster_with.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2179> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1107887] Speed up function calls/can add more introspection info
Changes by Jeffrey Yasskin: -- nosy: +jyasskin _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1107887> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1193577] add server.shutdown() method to SocketServer
Jeffrey Yasskin added the comment: Hearing no objections, I've submitted this as r61289. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1193577> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2179] with should be as fast as try/finally
Jeffrey Yasskin <[EMAIL PROTECTED]> added the comment: Thanks Nick and Amaury! Amaury, what times are you seeing? It could be a just-gcc speedup, but I wouldn't have thought so since the patch eliminates 2 times around the eval loop. It could be that the overhead of WITH_CLEANUP is high enough to drown out those iterations. You had mentioned optimizing the PyObject_CallFunctionObjArgs() call before. If you're still seeing with significantly slower than try, that's probably the right place to look. Here are my current timings. To avoid the lock issues, I wrote simple_cm.py containing: class CM(object): def __enter__(self): pass def __exit__(self, *args): pass $ ./python.exe -m timeit -s 'import simple_cm; cm = simple_cm.CM()' 'with cm: pass' 100 loops, best of 3: 0.885 usec per loop $ ./python.exe -m timeit -s 'import simple_cm; cm = simple_cm.CM()' 'cm.__enter__()' 'try: pass' 'finally: cm.__exit__()' 100 loops, best of 3: 0.858 usec per loop If __exit__ doesn't contain *args (making it not a context manager), the try/finally time goes down to: $ ./python.exe -m timeit -s 'import simple_cm; cm = simple_cm.CM()' 'cm.__enter__()' 'try: pass' 'finally: cm.__exit__()' 100 loops, best of 3: 0.619 usec per loop I think in theory, with could be slightly faster than finally with the same argument list, but it's pretty close now. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2179> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx
New submission from Jeffrey Yasskin <[EMAIL PROTECTED]>: I'm using Apple's gcc-4.0.1 on a 2.33GHz Intel Core 2 Duo to test this. Measurements from other compilers or other chips would be cool. Specifically, this patch: 1) Moves the declarations of most of the local variables inside the for(;;) loop. That shortens their lifetimes so that the compiler can skip spilling them to memory in some cases. Pushing them further down into the individual case statements didn't change the generated assembly in most cases, although there are probably a few opcodes where it would. 2) Eliminates the initialization of w, and fixes the "possibly used uninitialized" warning by changing how the PRINT opcodes initialize it from stream. That lets my compiler avoid using its stack entry most of the time. 3) In two hot opcodes, LOAD_FAST and LOAD_CONST, changes the 'x' to a 'w'. 'x' is always written to memory because it's used for error detection, while 'w' can stay on the stack. 4) Changes --_Py_Ticker in the periodic things check to _Py_Ticker--. Because _Py_Ticker is volatile, predecrement (at least on my compiler) needs 3 memory accesses, while postdecrement gets away with 2. Together, these changes are worth about 3% on pybench on my machine. -- components: Interpreter Core files: elim_mem_refs.patch keywords: patch, patch messages: 63426 nosy: jyasskin severity: normal status: open title: Helping the compiler avoid memory references in PyEval_EvalFrameEx type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9643/elim_mem_refs.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2262> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx
Jeffrey Yasskin <[EMAIL PROTECTED]> added the comment: Neal, t and stream aren't likely to have much effect since they're used so little. next_instr and stack_pointer are used to communicate between loops, so they can't move inside. I eagerly await your benchmark runs. :) Skip, I managed to reproduce the warnings with gcc-4.2.1, and while they're wrong, I see why they're happening. The if (throwflag) block skips to on_error, which misses the initializations of x and err. The right way to fix it is either to eliminate the error-reporting behavior of x and err or to extract on_error into a function, but for this patch I would probably just keep x and err out of the loop. Your numbers made me look closer at my results for individual tests, and I'm now confused about how reliable pybench is. My gcc-4.0 was build #5367 on OS X 10.4.11, and MacPorts' gcc-4.2.1 (with a necessary configure.in tweak) still shows a 1-2% gain overall. But contrary to your numbers, it gives me a 10% speedup in Recursion and a 1% slowdown in CompareFloatsIntegers. My big losers are SimpleListManipulation with an 18% loss on 4.2 and CompareInternedStrings with a 20% loss on 4.0, but those are both small winners (~5%) on the opposite compiler! I wouldn't be surprised if the overall numbers were different between even slightly different machines and compilers, but I'm really surprised to see the same tests affected in opposite directions. Is that common with pybench and compiler changes? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2262> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx
Changes by Jeffrey Yasskin <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file9648/elim_mem_refs.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2262> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
