Jeffrey Yasskin [EMAIL PROTECTED] added the comment:
I've fixed this in r61436 with a bunch of back pointers to the previous
issues. If anyone on old versions sees problems, we can add the flags
back conditionally.
--
resolution: accepted - fixed
status: open - closed
type: - compile
Jeffrey Yasskin [EMAIL PROTECTED] added the comment:
I reverted this in r61436 to fix issue 1779871. The long double is still
around, but the gcc bundled with OS X 10.4 doesn't warn about it anymore.
--
nosy: +jyasskin
Tracker [EMAIL PROTECTED]
http
Jeffrey Yasskin [EMAIL PROTECTED] added the comment:
I reverted this in r61436 to fix issue 1779871. Either the test has
changed in the mean time, or the gccs bundled since OS X 10.4 now
preserve the signs of 0.
--
nosy: +jyasskin
Tracker [EMAIL
Jeffrey Yasskin [EMAIL PROTECTED] added the comment:
Missed this. It's now fixed by r61438.
--
nosy: +jyasskin
status: open - closed
type: crash - behavior
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2319
New submission from Jeffrey Yasskin [EMAIL PROTECTED]:
class Meta(type):
... def __instancecheck__(self, other):
... return False
isinstance(3, Meta)
In 2.6, this results in:
Traceback (most recent call last):
File stdin, line 1, in module
RuntimeError: maximum recursion depth
Jeffrey Yasskin [EMAIL PROTECTED] added the comment:
Thanks! Fixed in r61472.
--
resolution: - accepted
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2313
Jeffrey Yasskin [EMAIL PROTECTED] added the comment:
Ludwig isn't really proposing that subprocess.Popen be thread-safe. That
would imply that you could mess with the same Popen instance
concurrently from separate threads, which shouldn't be allowed. But
instead, he's asking
Jeffrey Yasskin [EMAIL PROTECTED] added the comment:
Another data point: I just installed gcc-4.3.0, and the second patch
gives it a 6% speedup. On the downside, 4.3 is still about 9% slower
than 4.0. :-( Neal, do you have your measurements?
__
Tracker [EMAIL
Changes by Jeffrey Yasskin [EMAIL PROTECTED]:
--
type: behavior - performance
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2262
__
___
Python-bugs-list mailing list
Jeffrey Yasskin [EMAIL PROTECTED] added the comment:
Given Alexander's comment, and the fact that x==x must imply
hash(x)==hash(x) but the reverse need not be true, this seems like
intentional behavior.
--
nosy: +jyasskin
resolution: - invalid
status: open - closed
New submission from Jeffrey Yasskin [EMAIL PROTECTED]:
With the code as it stands, calls to shutdown that happen before
serve_forever enters its loop will deadlock, and there's no simple way
for the user to avoid this. The attached patch prevents the deadlock and
allows multiple serve_forever
New submission from Jeffrey Yasskin [EMAIL PROTECTED]:
r58099 added an exception to the common case of PyObject_IsInstance(),
when the class has no __instancecheck__ attribute. This makes
isinstance(3, int) take 4x as long as in python 2.5.
--
assignee: gvanrossum
components
Jeffrey Yasskin [EMAIL PROTECTED] added the comment:
So this has a race. See issue 2302 to discuss a fix.
--
resolution: - fixed
status: open - closed
superseder: - Uses of SocketServer.BaseServer.shutdown have a race
_
Tracker [EMAIL PROTECTED
Jeffrey Yasskin [EMAIL PROTECTED] added the comment:
It can. :)
--
status: pending - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1689
__
___
Python-bugs-list
Changes by Jeffrey Yasskin [EMAIL PROTECTED]:
--
assignee: - jyasskin
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2302
__
___
Python-bugs-list mailing list
Jeffrey Yasskin [EMAIL PROTECTED] added the comment:
I think this is still a problem at head, so it's not covered by the
comment about the bugfix releases. But there is another issue covering
the same thing... Since that one also has a patch and is a little newer,
I'll point this one over
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
Changes by Jeffrey Yasskin [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file9648/elim_mem_refs.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2262
Changes by Jeffrey Yasskin [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file9649/elim_mem_refs.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2262
__
___
Python
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
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
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
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
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
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
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
Jeffrey Yasskin added the comment:
Yep. Removed in r61162.
--
resolution: - out of date
status: open - closed
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1012468
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
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
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
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
Jeffrey Yasskin added the comment:
Submitted as r61100.
--
assignee: - jyasskin
resolution: - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2184
Changes by Jeffrey Yasskin:
--
nosy: +jyasskin
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1910
__
___
Python-bugs-list mailing list
Unsubscribe:
http
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
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
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
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
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
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
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
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
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
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
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
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.207
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
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
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
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
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
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
Jeffrey Yasskin added the comment:
Submitted as r60566.
--
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2002
__
___
Python-bugs-list mailing
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
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
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
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
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
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
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
Jeffrey Yasskin added the comment:
Done in r60480.
--
resolution: accepted - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1968
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
Changes by Jeffrey Yasskin:
--
resolution: - accepted
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1965
__
___
Python-bugs-list mailing list
Unsubscribe:
http
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
Jeffrey Yasskin added the comment:
Will do.
--
components: +Library (Lib)
resolution: - accepted
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1968
__
___
Python-bugs
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Jeffrey Yasskin added the comment:
Committed as r59809.
--
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1747
__
___
Python-bugs-list mailing
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
Jeffrey Yasskin added the comment:
Submitted as r59747.
--
keywords: +py3k
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1656
__
___
Python-bugs
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
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
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
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
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
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
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
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
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
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
Changes by Jeffrey Yasskin:
--
nosy: +jyasskin
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1450807
_
___
Python-bugs-list mailing list
Unsubscribe:
http
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
101 - 194 of 194 matches
Mail list logo
