[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC

Jeffrey Yasskin added the comment: Has enough time passed that you can use the C11 atomic types and operations instead of special-casing these for each compiler? (e.g. http://en.cppreference.com/w/c/atomic/atomic_store) -- ___ Python tracker <

[issue22038] Implement atomic operations on non-x86 platforms

Changes by Jeffrey Yasskin jyass...@gmail.com: -- nosy: -jyasskin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22038 ___ ___ Python-bugs-list

[issue10260] Add a threading.Condition.wait_for() method

Jeffrey Yasskin jyass...@gmail.com added the comment: On Tue, Nov 2, 2010 at 4:29 AM, Antoine Pitrou rep...@bugs.python.org 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

[issue10260] Add a threading.Condition.wait_for() method

Jeffrey Yasskin jyass...@gmail.com 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

[issue1676820] Add a PeriodicTimer to threading

Jeffrey Yasskin jyass...@gmail.com 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

[issue9189] Improve CFLAGS handling

Jeffrey Yasskin jyass...@gmail.com added the comment: Oops, sorry about that. Is the fix to change LDSHARED to LDSHARED= $(CC) $(PY_LDFLAGS) -bundle -undefined dynamic_lookup ? -- ___ Python tracker rep...@bugs.python.org http

[issue9189] Improve CFLAGS handling

Jeffrey Yasskin jyass...@gmail.com added the comment: Hearing no further comments, I've committed this as r82746. Let me know if it breaks anything. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http

[issue9189] Improve CFLAGS handling

Jeffrey Yasskin jyass...@gmail.com added the comment: Oops. Thanks for telling me. Fixed in r82753. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9189

[issue9189] Improve CFLAGS handling

New submission from Jeffrey Yasskin jyass...@gmail.com: Patch at http://codereview.appspot.com/1749042. The idea here is to let the user set CFLAGS on either configure or make (or both), and have later settings appear later in the $CC command line. I left OPT, BASECFLAGS, and EXTRA_CFLAGS

[issue9189] Improve CFLAGS handling

Jeffrey Yasskin jyass...@gmail.com added the comment: Passing in user values to CFLAGS on configure should already work without the patch. Since the user's CFLAGS settings are overridden by Python's OPT settings, it doesn't already work without the patch. I'm not sure why you'd want

[issue8800] add threading.RWLock

Jeffrey Yasskin jyass...@gmail.com added the comment: This patch doesn't apply cleanly against the py3k tree. Since Python 2.7 is in beta, and there's no 2.8, this can only go into python 3, so you should work against that tree. It's a bit annoying that the R in RWLock stands for a different

[issue8777] Add threading.Barrier

Jeffrey Yasskin jyass...@gmail.com added the comment: You should probably mention that pthread_barrier and java.util.concurrent.CyclicBarrier are prior art for this. I'm thinking about them when looking at the API to see whether your differences make sense. enter seems to be the wrong term

[issue8800] add threading.RWLock

Jeffrey Yasskin jyass...@gmail.com added the comment: In this case, acquire isn't ambiguous. All the other lock types actually acquire a write lock, so it makes sense to have the operation with the same name they use also acquire a write lock on this object. I realized that read/write locks

[issue8800] add threading.RWLock

Jeffrey Yasskin jyass...@gmail.com added the comment: You're definitely right that posix and java don't make these usable from the normal lock API. And I don't think it's essential that they be usable as RLocks, although it's nice for Conditions. I think what I'm actually saying

[issue8726] test_capi failure

Jeffrey Yasskin jyass...@gmail.com added the comment: Fixed in r81269. Sorry about that. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8726

[issue8726] test_capi failure

Jeffrey Yasskin jyass...@gmail.com added the comment: Ah, darn. Any thoughts on what do to? Shall I make the test conditional on a pydebug build, or just remove it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8726

[issue3605] Py_FatalError causes infinite loop

Jeffrey Yasskin jyass...@gmail.com added the comment: Fixed in r81142. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3605

[issue3605] Py_FatalError causes infinite loop

Jeffrey Yasskin jyass...@gmail.com 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

[issue8566] 2to3 should run under python 2.5

Jeffrey Yasskin jyass...@gmail.com 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

[issue8566] 2to3 should run under python 2.5

Jeffrey Yasskin jyass...@gmail.com 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 rep...@bugs.python.org http

[issue8566] 2to3 should run under python 2.5

Jeffrey Yasskin jyass...@gmail.com added the comment: Done. -- keywords: -needs review stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8566

[issue8566] 2to3 should run under python 2.5

New submission from Jeffrey Yasskin jyass...@gmail.com: 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

[issue8553] 2to3 breaks relative imports

New submission from Jeffrey Yasskin jyass...@gmail.com: 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

[issue8553] 2to3 breaks relative imports

Jeffrey Yasskin jyass...@gmail.com added the comment: Thanks! Committed as r80573. -- keywords: -needs review stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8553

[issue7316] Add a timeout functionality to common locking operations

Jeffrey Yasskin jyass...@gmail.com added the comment: Thanks, looks good. Sorry for the delay. -- resolution: - accepted ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7316

[issue8032] Add gdb7 hooks to make it easier to debug Python

Jeffrey Yasskin jyass...@gmail.com 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

[issue8032] Add gdb7 hooks to make it easier to debug Python

Changes by Jeffrey Yasskin jyass...@gmail.com: -- nosy: +jyasskin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8032 ___ ___ Python-bugs-list

[issue7316] Add a timeout functionality to common locking operations

Jeffrey Yasskin jyass...@gmail.com added the comment: I don't object strongly, but since locks are supposed to be held for short amounts of time, a timeout shouldn't be that useful, and when people really need it they can put it together with a condition variable. Timeouts also interact

[issue7316] Add a timeout functionality to common locking operations

Jeffrey Yasskin jyass...@gmail.com added the comment: Timeouts also interact poorly with condition variables: you can time out the initial acquire, but if you wait on a condition there's no place to put the timeout on the reacquire. I don't see how it's an objection. If you have a condition

[issue6431] Fraction fails equality test with a user-defined type

Jeffrey Yasskin jyass...@gmail.com added the comment: The fallback behavior in Fraction was meant to demonstrate the suggested fallback behavior for user-defined types. In particular, the idea was that all Reals would (by default) be comparable to each other, even if they didn't know about

[issue6431] Fraction fails equality test with a user-defined type

Jeffrey Yasskin jyass...@gmail.com added the comment: If you think it's better, I'm happy to make the other tradeoff. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6431

[issue6042] Document and slightly simplify lnotab tracing

Jeffrey Yasskin jyass...@gmail.com added the comment: Committed to trunk in r72879. I'll wait to merge it to 3.x until 3.1 has been released, since we're approaching the release candidate there. -- stage: patch review - committed/rejected ___ Python

[issue6042] Document and slightly simplify lnotab tracing

Changes by Jeffrey Yasskin jyass...@gmail.com: -- assignee: - jyasskin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6042 ___ ___ Python-bugs

[issue6042] Document and slightly simplify lnotab tracing

Jeffrey Yasskin jyass...@gmail.com added the comment: I had two reasons to change PyCode_CheckLineNumber to _PyCode_CheckLineNumber: First, its behavior is changing without its signature changing. Without a name change, that could break users silently (if there are any codesearch missed). Second

[issue6042] Document and slightly simplify lnotab tracing

Jeffrey Yasskin jyass...@gmail.com added the comment: I've fixed #1689458. Here's a new version of the patch with the simplifying tweaks to PyCode_CheckLineNumber() so y'all can see what that looks like. If I don't get any substantive comments by the weekend (thanks Antoine for the docs +1

[issue1689458] pdb unable to jump to first statement

Jeffrey Yasskin jyass...@gmail.com added the comment: Fixed in r72796. Will forward-port to py3k shortly. -- stage: patch review - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1689458

[issue1689458] pdb unable to jump to first statement

Jeffrey Yasskin jyass...@gmail.com added the comment: Merged to py3k in r72809. -- status: open - closed versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1689458

[issue1689458] pdb unable to jump to first statement

Jeffrey Yasskin jyass...@gmail.com added the comment: The attached patch fixes this problem and adds a test. I'll wait a day for any comments before committing it. Review at http://codereview.appspot.com/67063. -- keywords: +needs review, patch nosy: +jyasskin stage: test needed - patch

[issue6042] Document and slightly simplify lnotab tracing

New submission from Jeffrey Yasskin jyass...@gmail.com: lnotab-based tracing is very complicated and isn't documented very well. There were at least 3 comment blocks purporting to document co_lnotab, and none did a very good job. This patch unifies them into Objects/lnotab_notes.txt which tries

[issue1200] Allow array.array to be parsed by the t# format unit.

Jeffrey Yasskin jyass...@gmail.com added the comment: I actually have no idea what I was trying to do when I ran into this. I think it was a use somewhere in the standard libraries rather than my own code, so if uses of t# are gone from there, I'd have no objections to closing this bug

[issue5970] sys.exc_info leaks into a generator

Jeffrey Yasskin jyass...@gmail.com added the comment: Re py3k: oops, thanks for checking. Re 2.6: Fine with me, second patch removed. -- assignee: barry - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5970

[issue5970] sys.exc_info leaks into a generator

Changes by Jeffrey Yasskin jyass...@gmail.com: Removed file: http://bugs.python.org/file13928/exc_info_26.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5970

[issue5970] sys.exc_info leaks into a generator

New submission from Jeffrey Yasskin jyass...@gmail.com: There's an obscure bug in sys.exc_info after a yield statement. def test(): def raising_generator(): try: raise IndexError(inner exception) except IndexError: yield 3

[issue5970] sys.exc_info leaks into a generator

Jeffrey Yasskin jyass...@gmail.com added the comment: I think we should _not_ backport any fix for this bug to the 2.6 series, since any changes to user behavior would be pretty subtle. To prevent that backport, I'd like to apply exc_info_26.patch to the 2.6 branch, with Barry's approval

[issue5959] PyCode_NewEmpty

Jeffrey Yasskin jyass...@gmail.com added the comment: Documented, tested, and committed to 2.7 as r72487. This should be forward-ported to 3.x also, but since we've already started the betas for 3.1, it should probably wait for 3.2. -- keywords: -needs review

[issue5954] PyFrame_GetLineNumber

Jeffrey Yasskin jyass...@gmail.com added the comment: Documented and committed as r72488. This should be forward-ported to 3.x also, but since we've already started the betas for 3.1, it should probably wait for 3.2. -- keywords: -needs review

[issue5954] PyFrame_GetLineNumber

New submission from Jeffrey Yasskin jyass...@gmail.com: Most uses of PyCode_Addr2Line (http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get the line number of a specified frame, but there's no way to do that directly. Forcing people to go through the code object makes them

[issue5959] PyCode_NewEmpty

New submission from Jeffrey Yasskin jyass...@gmail.com: Most uses of PyCode_New found by http://www.google.com/codesearch?q=PyCode_New are trying to build an empty code object, usually to put it in a dummy frame object. This patch adds a PyCode_NewEmpty wrapper which lets the user specify just

[issue1540386] SocketServer.ForkingMixIn.collect_children() waits on pid 0

Jeffrey Yasskin jyass...@gmail.com added the comment: Yes, sorry. That was fixed in r69927. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1540386

[issue5812] Fraction('1e6') should be valid.

Jeffrey Yasskin jyass...@gmail.com added the comment: Sounds good to me. I can't find any real objections to the new format in issue 1682, just me complaining that it might be feature creep. -- ___ Python tracker rep...@bugs.python.org http

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

Jeffrey Yasskin jyass...@gmail.com added the comment: Hold off on reviewing this. There's one bug around the peepholer not turning itself off when line numbers skip by more than 127, and another around the traceback generator still assuming line numbers are unsigned. I'll post another patch when

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

Jeffrey Yasskin jyass...@gmail.com added the comment: No particular reason for cPickle. It sometimes shows when we've caused problems by increasing the code size, and shows the size of any random effects that the compiler causes by moving code around. Could you double-check the patch to see if I

[issue4715] optimize bytecode for conditional branches

Jeffrey Yasskin jyass...@gmail.com added the comment: Backported as r70071. I also fixed a couple things I missed in the py3k branch in r70076. Thanks all! -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http

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

Jeffrey Yasskin jyass...@gmail.com added the comment: I've updated for_iter.patch to the latest trunk, merging in issue 4715. I also changed tracing a bit so that the first line of a loop doesn't get traced twice in the first iteration, and added to test_dis to check that decreasing line numbers

[issue4715] optimize bytecode for conditional branches

Jeffrey Yasskin jyass...@gmail.com added the comment: Collin made some comments at http://codereview.appspot.com/20094. Here's a new patch that fixes them. I plan to commit it over the weekend and then start on issue 2459. Added file: http://bugs.python.org/file13208/trunk-opt-cond-jump.patch

[issue4715] optimize bytecode for conditional branches

Jeffrey Yasskin jyass...@gmail.com added the comment: Oh, and no problem with picking up the patches. Thanks for writing them in the first place. Here's the backport to trunk. I particularly enjoyed the bit in pyassem.py where I had to teach the pure-Python compiler that you can get to a block

[issue4715] optimize bytecode for conditional branches

Jeffrey Yasskin jyass...@gmail.com added the comment: The numbers are: Intel Core 2, gcc-4.3, 32-bit 2to3: 25.24 - 24.89: 1.38% faster Django: Min: 0.618 - 0.607: 1.90% faster Avg: 0.621 - 0.615: 1.04% faster PyBench: Min: 5324 - 5280: 0.83% faster Avg: 5456 - 5386: 1.30% faster Pickle: Min

[issue4715] optimize bytecode for conditional branches

Jeffrey Yasskin jyass...@gmail.com added the comment: I've updated Antoine's patch to incorporate my comments. This interacts with issue 2459, but I haven't yet looked at its patch to figure out how. As a first cut, I'll propose committing this patch, backporting it to trunk, syncing

[issue5362] Add configure option to disable Py3k warnings

Jeffrey Yasskin jyass...@gmail.com added the comment: s/Leaving/Turning/ in configure.in. It looks like the convention for other --with flags that default to enabled is to document them as --with(out)-xxx. (except tsc...) I guess it's probably even better just to say what the default

[issue4715] optimize bytecode for conditional branches

Jeffrey Yasskin jyass...@gmail.com added the comment: Committed as r69961. I'll post the backport to trunk here at least a day before I commit it. -- type: resource usage - performance versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org

[issue5176] Special-case string formatting in BINARY_MODULO implementation

Jeffrey Yasskin jyass...@gmail.com added the comment: Looks good to me. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5176 ___ ___ Python-bugs-list mailing

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by Jeffrey Yasskin jyass...@gmail.com: -- nosy: +collinwinter, jyasskin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4258 ___ ___ Python

[issue5176] Special-case string formatting in BINARY_MODULO implementation

Jeffrey Yasskin jyass...@gmail.com added the comment: I think this is only valid when PyString_CheckExact is true. A subclass could override __mod__, right? I'm somewhat interested to see how a primarily-numeric benchmark responds to this patch. I'd expect it to get very slightly slower

[issue4753] Faster opcode dispatch on gcc

Jeffrey Yasskin jyass...@gmail.com added the comment: In the comment, you might mention both -fno-crossjumping and -fno-gcse. -fno-crossjumping's description looks like it ought to prevent combining computed gotos, but http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Optimize-Options.html says -fno

[issue4998] __slots__ on Fraction is useless

Jeffrey Yasskin jyass...@gmail.com added the comment: Rational has default definitions for some of its methods and properties. If Fraction inherits from Rational, it gets those definitions implicitly. If it's registered with Rational, it has to define them itself. I don't know that much about

[issue4941] Tell GCC Py_DECREF is unlikely to call the destructor

Jeffrey Yasskin jyass...@gmail.com added the comment: Minor comments on likely_object.diff: * Py_LIKELY() and Py_UNLIKELY() would be better spellings than likely() and unlikely(). * The definitions should go in pyport.h instead of object.h * Usually don't put spaces after the #. * Probably

[issue4896] Faster why variable manipulation in ceval.c

Changes by Jeffrey Yasskin jyass...@gmail.com: -- nosy: +collinwinter, jyasskin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4896 ___ ___ Python

[issue4888] misplaced (or misleading) assert in ceval.c

Jeffrey Yasskin jyass...@gmail.com added the comment: The assert seems confusing to me because it's overly specific. It causes me to ask, what's special about WHY_YIELD that why might be set to it? If I understand the loop correctly, we could rewrite the top as: assert(why != WHY_YIELD

[issue4715] optimize bytecode for conditional branches

Jeffrey Yasskin jyass...@gmail.com added the comment: Looking through the patch... I don't really like the names for JUMP_OR_POP and POP_OR_JUMP. (They don't really indicate to me that the choice depends on the truth of the top of the stack.) How about JUMP_IF_FALSE_OR_POP

[issue4753] Faster opcode dispatch on gcc

Jeffrey Yasskin jyass...@gmail.com added the comment: Here's the vmgen-based patch for comparison. Again, it passes all the tests, but isn't complete outside of that and (unless consensus develops that a couple percent is worth requiring vmgen) shouldn't distract from reviewing Antoine's patch

[issue4753] Faster opcode dispatch on gcc

Jeffrey Yasskin jyass...@gmail.com added the comment: I've left some line-by-line comments at http://codereview.appspot.com/11905. Sorry if there was already a Rietveld thread; I didn't see one. ___ Python tracker rep...@bugs.python.org http://bugs.python.org

[issue4753] Faster opcode dispatch on gcc

Jeffrey Yasskin jyass...@gmail.com added the comment: @Paolo: I'm going to be looking into converting more common sequences into superinstructions. We only have LOAD_CONST+XXX so far. The others are difficult because vmgen doesn't provide easy ways to deal with error handling, but Jakob and I

[issue4753] Faster opcode dispatch on gcc

Jeffrey Yasskin jyass...@gmail.com added the comment: Here's a port of threadedceval5.patch to trunk. It passes the tests. I haven't benchmarked this exact patch, but on one Intel Core2, a similar patch got an 11%-14% speedup (on 2to3 and pybench). I've also cleaned up Jakob Sievers' vmgen

[issue4884] Work around gethostbyaddr_r bug

Jeffrey Yasskin jyass...@gmail.com added the comment: socket_gethostbyname_ex() calls gethostbyname_r() rather than gethostbyaddr_r(), and that appears not to have the bug. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4884

[issue4884] Work around gethostbyaddr_r bug

Jeffrey Yasskin jyass...@gmail.com added the comment: Committed as r68450. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4884

[issue4884] Work around gethostbyaddr_r bug

New submission from Jeffrey Yasskin jyass...@gmail.com: glibc until 2.10 has a bug in gethostbyaddr_r that assumes the buffer argument is 8-byte aligned (http://sources.redhat.com/ml/libc-alpha/2009-01/msg0.html). gcc seems to always provide such alignment for the call

[issue4753] Faster opcode dispatch on gcc

Changes by Jeffrey Yasskin jyass...@gmail.com: -- nosy: +collinwinter, jyasskin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4753 ___ ___ Python

[issue4707] round() shows undocumented behaviour

Jeffrey Yasskin jyass...@gmail.com added the comment: When PEP 3141 says something should be Real, that includes both int and float as possibilities (since Real is a supertype of Integral), so it's consistent with the PEP for round(int, int) to return an int, and I agree with Mark that round(25

[issue2183] optimize list comprehensions

Changes by Jeffrey Yasskin jyass...@gmail.com: -- nosy: +jyasskin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2183 ___ ___ Python-bugs-list

[issue4477] Speed up PyEval_EvalFrameEx when tracing is off.

Jeffrey Yasskin jyass...@gmail.com added the comment: Merged to 3.1 in r67611, 3.0.x in r67721, and 2.6.x in r67722. -- keywords: -needs review status: open - closed versions: +Python 2.6 ___ Python tracker rep...@bugs.python.org http

[issue4597] EvalFrameEx fails to set 'why' for some exceptions

Jeffrey Yasskin [EMAIL PROTECTED] added the comment: Added NEWS in r67685; ported to 2.5 branch in r67687; to 2.6 branch in r67696; to 3.1 branch in r67697; and to 3.0 branch in r67698. -- status: open - closed ___ Python tracker [EMAIL PROTECTED

[issue4589] 'with' loses -bool exceptions

Jeffrey Yasskin [EMAIL PROTECTED] added the comment: It's a corner case that would confuse anyone who ran into it, so I'm happy to backport it. I'll probably just re-do your patch on the 2.5 branch since WITH_CLEANUP has a different structure

[issue4589] 'with' loses -bool exceptions

Jeffrey Yasskin [EMAIL PROTECTED] added the comment: I think your patch leaks a reference to 'x'. Move the Py_DECREF(x) to before if (err 0)? And then really nitpicky: your test has 3 blank lines after it, and should have 2. Otherwise looks great. Thanks for picking this up

[issue4589] 'with' loses -bool exceptions

Jeffrey Yasskin [EMAIL PROTECTED] added the comment: Looks good. Thanks! I assume this should be merged into the 2.6.x and 3.0.x branches? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4589

[issue4597] EvalFrameEx fails to set 'why' for some exceptions

New submission from Jeffrey Yasskin [EMAIL PROTECTED]: Several opcodes that can raise an exception fail to set x, err, or why afterward. This patch fixes all the examples I could find. I could only figure out how to write a test for PRINT_NEWLINE; the others are hard to trigger

[issue4597] EvalFrameEx fails to set 'why' for some exceptions

Jeffrey Yasskin [EMAIL PROTECTED] added the comment: Submitted as r67666. I'll ping Martin. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4597

[issue4589] 'with' loses -bool exceptions

New submission from Jeffrey Yasskin [EMAIL PROTECTED]: When a context manager's __exit__() method returns an object whose conversion to bool raises an exception, 'with' loses that exception. For example: class CM(object): ... def __init__(self, exit_result): ... self.exit_result

[issue4477] Speed up PyEval_EvalFrameEx when tracing is off.

Jeffrey Yasskin [EMAIL PROTECTED] added the comment: Thanks for the review, Raymond. Committed to the trunk in r67494. I'll svnmerge it over to 3.0.1 once Barry unfreezes the branches. Martin, let me know if you analyze this any more and find anything interesting. -- stage: commit

[issue4477] Speed up PyEval_EvalFrameEx when tracing is off.

Jeffrey Yasskin [EMAIL PROTECTED] added the comment: Martin, does your comment mean you think this should stay out of the trunk(s) until 3.0 is released? That's fine. How about after that: should it go in the 2.6.x and 3.0.x branches too? ___ Python tracker

[issue4477] Speed up PyEval_EvalFrameEx when tracing is off.

New submission from Jeffrey Yasskin [EMAIL PROTECTED]: Tracing support shows up fairly heavily an a Python profile, even though it's nearly always turned off. The attached patch against the trunk speeds up PyBench by 2% for me. All tests pass. I have 2 questions: 1) Can other people corroborate

[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

[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

[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

[issue2748] ceil(), floor() and round() broken in Decimal

Jeffrey Yasskin [EMAIL PROTECTED] added the comment: I remember the answer being that they shouldn't be supported, but then I stopped paying attention and some patches went in bringing Decimal closer to the Real API again, so I'm not sure if the earlier discussion still applies. I'm happy to let

[issue1068268] subprocess is not EINTR-safe

Jeffrey Yasskin [EMAIL PROTECTED] added the comment: I think the proper behavior on EINTR may depend on which subprocess call we're in. For example, the user can easily loop on .wait() herself if she wants to ignore EINTR. But it's a lot harder to loop on Popen() if the read() in _execute_child

[issue815646] thread unsafe file objects cause crash

Changes by Jeffrey Yasskin [EMAIL PROTECTED]: -- nosy: +jyasskin Tracker [EMAIL PROTECTED] http://bugs.python.org/issue815646 ___ Python-bugs-list mailing list

[issue2507] Exception state lives too long in 3.0

Jeffrey Yasskin [EMAIL PROTECTED] added the comment: Thanks for the patch. This isn't specific to threads at all, so the test doesn't need to spawn a thread, just raise an exception from a nested function with a parameter, catch it, delete the object the parameter referred to, and then check

[issue2496] test_no_refcycle_through_target sometimes fails in test_threading

Jeffrey Yasskin [EMAIL PROTECTED] added the comment: I'll look at this tonight. -- assignee: - jyasskin nosy: +jyasskin __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2496

[issue2496] test_no_refcycle_through_target sometimes fails in test_threading

Jeffrey Yasskin [EMAIL PROTECTED] added the comment: I think I've confirmed your diagnosis. If I add a _sleep(.01) to Thread.__bootstrap_inner() just after the call to self.__stop(), the test fails reliably. Very good catch! Given that, I think just adding a short sleep to the test before

[issue2459] speedup loops with better bytecode

Changes by Jeffrey Yasskin [EMAIL PROTECTED]: -- nosy: +jyasskin __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2459 __ ___ Python-bugs-list mailing list Unsubscribe

  1   2   >