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.
Changes by Jeffrey Yasskin:
--
nosy: +jyasskin
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1450807>
_
___
Python-bugs-list mailing list
Unsubs
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.pyth
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 mak
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/
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 sa
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
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
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!
__
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 isins
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://
Changes by Jeffrey Yasskin :
--
nosy: +jyasskin
___
Python tracker
<http://bugs.python.org/issue8032>
___
___
Python-bugs-list mailing list
Unsubscribe:
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?
--
___
Jeffrey Yasskin added the comment:
Thanks, looks good. Sorry for the delay.
--
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/iss
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,
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/
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. A
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?
--
___
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/issue8
Jeffrey Yasskin added the comment:
Done.
--
keywords: -needs review
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
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: +jyassk
Jeffrey Yasskin added the comment:
Fixed in r81142.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
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:
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
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.p
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:
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
Jeffrey Yasskin added the comment:
Right. Will do.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1623>
__
___
Python-bugs-list mailing list
Unsubs
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
Jeffrey Yasskin added the comment:
Submitted as r59747.
--
keywords: +py3k
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1656>
__
___
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 ref
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
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>
__
___
P
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 <[EM
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
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
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.p
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
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 statement
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 de
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 sc
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.pytho
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 p
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 aw
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:
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 contentiou
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 t
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/
Changes by Jeffrey Yasskin:
--
resolution: -> accepted
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1965>
__
___
Python-bugs-list mailing list
Uns
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
Jeffrey Yasskin added the comment:
Will do.
--
components: +Library (Lib)
resolution: -> accepted
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1968>
__
___
Jeffrey Yasskin added the comment:
Done in r60480.
--
resolution: accepted -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
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.pytho
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.
--
as
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
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 exactl
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.p
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'
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.
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,
Jeffrey Yasskin added the comment:
Submitted as r60566.
--
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2002>
__
___
P
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
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
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,
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 AB
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 bloc
Jeffrey Yasskin added the comment:
I've committed the inlined option as r60762.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1762>
__
___
Python-bugs-
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:
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
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
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__ = ["n
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.
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
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 availa
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
Changes by Jeffrey Yasskin:
--
nosy: +jyasskin
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1910>
__
___
Python-bugs-list mailing list
Unsubs
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
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.p
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 t
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
Jeffrey Yasskin added the comment:
Submitted as r61100.
--
assignee: -> jyasskin
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
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
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
Changes by Jeffrey Yasskin:
--
status: pending -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1183>
__
___
Python-bugs-list mailing li
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 dupli
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&
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 kno
Jeffrey Yasskin added the comment:
Yep. Removed in r61162.
--
resolution: -> out of date
status: open -> closed
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
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 r
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.or
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
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/
Changes by Jeffrey Yasskin:
--
nosy: +jyasskin
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1107887>
_
___
Python-bugs-list mailing list
Unsubs
Jeffrey Yasskin added the comment:
Hearing no objections, I've submitted this as r61289.
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1193577>
_
___
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
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 variable
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. :
Changes by Jeffrey Yasskin <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file9648/elim_mem_refs.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
1 - 100 of 206 matches
Mail list logo
