[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 <rep...@bugs.python.org> <http://bugs.python.org/issue30747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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? 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 rep...@bugs.python.org 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 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 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 rep...@bugs.python.org http://bugs.python.org/issue10260 ___ ___ 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 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). 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 rep...@bugs.python.org http://bugs.python.org/issue1676820 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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://bugs.python.org/issue9189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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://bugs.python.org/issue9189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 around in case people have written scripts using them, but I think they're superfluous as user-visible knobs after this patch. I prevented AC_PROG_CC from setting a default $CFLAGS value because the values it would set are already put into $BASECFLAGS when appropriate, and @CFLAGS@ needs to appear after @BASECFLAGS@ to allow the user to override Python's defaults at configure time. We could also accomplish this by removing BASECFLAGS and OPT entirely and instead prepending their contents to $CFLAGS in configure. That's a bigger patch, but if any of you feel strongly about it I can do that instead. I made the same changes for CPPFLAGS and LDFLAGS but no other user-settable variables. I don't have strong opinions about the exact set we support this for, as long as it includes CFLAGS, but these three seemed like a sensible set. -- messages: 109481 nosy: brett.cannon, jyasskin, lemburg, loewis, pitrou priority: normal severity: normal status: open title: Improve CFLAGS handling versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to modify CFLAGS on Makefile. If I run `make clean; make CFLAGS=-Werror`, I expect that to add -Werror to the compilation line. I don't expect it to replace all of the flags configure set up, and I don't expect to have to re-run configure to add the -Werror. Doing this won't affect distutils' behavior and won't automatically cause all of Python to get recompiled, so it's not something people should do when installing Python, but it's helpful during development. We've already had a long discussion about the use of AC_PROG_CC on another ticket. We are you trying to remove the default setting again ? BASECFLAGS is not supported by autoconf, it's a Python invention. Do you really want to put all the logic that autoconf uses to setup CFLAGS currently and in the future into our own configure code ? Are you willing to maintain that code ? Given that AC_PROG_CC, in its entire history, has only grown the ability to check for -g and -O2, I'm not too worried. Our configure code already uses $ac_cv_prog_cc_g to take advantage of AC_PROG_CC's detection of -g, and we have more sophisticated logic around -O2 than it does. (Check the configure source if you don't believe that AC_PROG_CC's CFLAGS handling is pretty simple.) We've also discussed switching the order of $(OPT) and $(CFLAGS): that doesn't work, since $(OPT) is meant to override the $(CFLAGS) settings. It's meant to override AC_PROG_CC's bad CFLAGS settings. Once those are out of the way, we don't need to surprise users with a non-working CFLAGS anymore. I made the same changes for CPPFLAGS and LDFLAGS but no other user-settable variables. I don't have strong opinions about the exact set we support this for, as long as it includes CFLAGS, but these three seemed like a sensible set. Some more comments: I don't really like the approach you've taken with the variable naming. It's better to stick to Makefile all caps standards and instead prepend Python specific variables with a PY or PY_ prefix. The already existing PY_CFLAGS should then be renamed to PY_RUNTIME_CFLAGS or just PYTHON_CFLAGS. Sure. Please also keep the default values for CFLAGS et al around, ie. CFLAGS = @CFLAGS@ PY_CFLAGS = $(BASECFLAGS) $(CFLAGS) $(OPT) $(EXTRA_CFLAGS) This doesn't quite work, since the make command line overrides that CFLAGS assignment. I've saved the configure-provided values into CONFIGURE_CFLAGS, etc. Note that using := will cause trouble with non-GNU makes. Why do you need this ? http://www.openbsd.org/cgi-bin/man.cgi?query=make and http://www.freebsd.org/doc/en/books/pmake/variables.html say bsd make supports :=. I'm not sure where to find docs for other makes. I don't need := anymore, though, since I found another way to fix sysconfig. Removed. In summary: While we're breaking Makefile parsing anyway, we might as well go for the big patch and remove the whole BASECFLAGS, OPT and EXTRA_CFLAGS cruft. These cause all sorts of problem when building extensions for Python and not even distutils always gets them right (distutils needs to mimic the CFLAGS setup when setting up the compiler, so it has to replicate what's going on in the Makefile in distutils.utils.ccompiler.customize_compiler()). Makefile parsing isn't the only thing we care about compatibility with. I kept them around for people who've been setting them through build scripts or who are just used to setting them on the command line. Maybe they should go away too, but I think that's orthogonal to this patch, and should happen with a lag (maybe a whole release) to let people get used to CFLAGS first. That is, unless you can point out practical problems with the change around AC_PROG_CC. I've uploaded the new patch to http://codereview.appspot.com/1749042. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9189 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 word from in RLock. But I can't think of a better name. Hm, the test for RWLock should use a Barrier to check for multiple readers. I wonder if it makes sense to add a DeadlockError as a subclass of RuntimeError and throw that from trying to upgrade a read-lock to a write-lock. The docs should describe why upgrading a read-lock to a write-lock is banned, or else people will try to add the feature. test_wrrecursion should also check pure writer recursion. Oh, no, that's tested by RLockTests. Comment that please. The name of the test should probably mention write_then_read_recursion to distinguish it from write-then-write or read-then-write. test_readers_writers doesn't quite test enough. (Feel free to add another test rather than changing this one.) You want to test that readers can't starve writers. For example, say we have: lock = RWLock() done = False def r(): with lock.rdlocked(): if done: return _wait() def w(): nonlocal done with lock.wrlocked(): done = True readers = Bunch(r, 50) _wait() writers = Bunch(w, 1) readers.wait_for_finished() writers.wait_for_finished() In a naive implementation, there may never be a point where no reader has the lock held, and so the writer may never get in to tell them all to exit. I believe your implementation will already pass this test. spelling: mathced I'm not sure that #threads will be few is true for a read-lock, but I don't mind for the first implementation. Generally put a space after # when it introduces a comment, start comments with a capital letter, and end them with punctuation so we know you didn't stop typing early. In _rdlock could you flip the not self.nw condition? That way the else won't be a double-negative. Can self.rcond.wait() ever throw an exception? I suspect you should use try:finally: to guard the self.nr -= 1 Why must the user hold a write lock to use Condition.wait? Semantically, a waiting on a read-lock would release the current thread's recursive read-locks, and all should be well. It looks like self.owning holds one copy of each thread's id for each re-entry by that thread. That wasn't obvious so deserves a comment. General API questions: 1. Given that the other locking APIs use acquire and release instead of lock and unlock, perhaps this class should use rdacquire and wracquire? 2. I wonder if it helps actual code to be able to just call unlock instead of rdunlock and wrunlock. Code releasing the lock should always know which kind of lock it holds. Otherwise, this looks basically correct. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8800 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 for this, since there's no matching exit call. wait or block seem better. Both pthread_barrier and CyclicBarrier provide a way to identify a unique thread from each group. pthread_barrier_wait returns true in exactly one thread, while CyclicBarrier runs a callback while all other threads are still paused. I'd be inclined to use CyclicBarrier's interface here, although then you have to define what happens when the action raises an exception. _release should notify_all after its loop. adjust_count makes me nervous. Is there a context manager interface that would make this cleaner/safer? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 are actually shared/exclusive locks, which might form the basis for a name that doesn't collide with RLock. Boost (http://www.boost.org/doc/libs/1_43_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_types.shared_mutex) uses shared_mutex for the concept, so SLock or SELock? There are some algorithms that write while the lock is acquired non-exclusive, so shared is actually a better name for the concept, even though posix and Java used read/write. The possibility of lock downgrading (turning an exclusive lock into a shared lock, without allowing any other exclusive acquisitions in the mean time) might inform your decision about how to name unlock. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8800 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 is that, if you have an acquire() operation on RWLock, then it has to forward to the write lock. Forwarding to the read lock would have different semantics from RLock.acquire (2 threads could get in at once) and so would be incorrect. I agree that RWLock is more obvious. As long as the docs mention that it's equivalent to a shared/exclusive lock, I don't care that much about the name. Just throwing out ideas. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8800 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ 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 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 ___ ___ 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 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: +jyasskin stage: unit test needed - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3605 ___ ___ 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 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? -- ___ Python tracker rep...@bugs.python.org 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 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://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 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 ___ ___ 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 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 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 rep...@bugs.python.org http://bugs.python.org/issue8566 ___ ___ 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 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 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 rep...@bugs.python.org 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 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 ___ ___ 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 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 ___ ___ 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 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? -- ___ Python tracker rep...@bugs.python.org 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
Changes by Jeffrey Yasskin jyass...@gmail.com: -- nosy: +jyasskin ___ Python tracker rep...@bugs.python.org 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 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 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. Given that it's hard to pick a timeout in most cases anyway, I think it'd be a much bigger win to figure out thread interruption. (Yes, I know that's hard, and that I promised to do it a long while ago and never got around to it.) That said, I have no objections at all to adding an internal timeout ability for use by Condition.wait, and if you're still enthusiastic about adding the timeout given the above argument, I won't block you. -- nosy: +jyasskin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7316 ___ ___ 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 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 variable you just use the cv's timeout feature, don't you? I guess there are already tons of combinations which don't make sense anyway. The cv's timeout stops waiting for the cv to be notified, but then it just calls acquire() with no timeout. Given that it's hard to pick a timeout in most cases anyway, I think it'd be a much bigger win to figure out thread interruption. (Yes, I know that's hard, and that I promised to do it a long while ago and never got around to it.) What do you mean by thread interruption? Cancellation? Yes, sorry, I was using the Java term, which isn't particularly accurate. That said, I have no objections at all to adding an internal timeout ability for use by Condition.wait, and if you're still enthusiastic about adding the timeout given the above argument, I won't block you. Well, it's pretty basic functionality provided by the underlying OS APIs, which is why I think it would be good to expose it. I remember being annoyed by its absence, but it was a long time ago and I don't remember which problem I was trying to solve. Fair enough. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7316 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 each other. Unfortunately, the comparison protocol provides no way to know if a particular call is the first call or the fallback, so __eq__(Fraction, b) has to return the same thing as __eq__(b, Fraction). If b doesn't know about Fraction, and Fraction wants to make a best attempt at comparing to it, then __eq__(Fraction, b) can't return NotImplemented. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker rep...@bugs.python.org http://bugs.python.org/issue6042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, I think it's an internal function which we should feel free to change again if it makes the implementation cleaner. In order to let people change it at will, it should start with _Py. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 :), I'll assume I've looked at this code longer than anyone in the last 7 years and commit it. :) -- Added file: http://bugs.python.org/file14038/lnotab.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [unladen-swallow] PEP 384: Defining a Stable ABI
A couple thoughts: I'm with the people who think the refcount should be accessed through functions by apps that want ABI compatibility. In particular, GIL-removal efforts are guaranteed to change how the refcount is modified, but there's a good chance they wouldn't have to change the API. (We have some ideas for how to maintain source compatibility in the absence of a GIL: http://code.google.com/p/unladen-swallow/wiki/ExtensionModules#Reference_Counting) Over an 8-year lifetime for Python 3, Moore's law predicts that desktop systems will have up to 64 cores, at which point even the simplest GIL-removal strategy of making refcounts atomic will be a win, despite the 2x performance loss for a single thread. I wouldn't want an ABI to rule that out. I do think the refcounting macros should remain present in the API (not ABI) for apps that only need source compatibility and want the extra speed. I wonder if it makes sense to specify an API compatibility mode in this PEP too. Py_LIMITED_API may not be the right macro name—it didn't imply anything about an ABI when I first saw it. Might it make sense to use Py_ABI_COMPATIBILITY=### instead? (Where ### could be an ISO date like 20090520.) That would put ABI in the macro name and make it easier to define new versions later if necessary. (New versions would help people compile against a new version of Python and be confident they had something that would run against old versions.) If we never define a new version, defining it to a number instead of just anything doesn't really hurt. It's probably worth pointing out in the PEP that the fact that PyVarObject.ob_size is part of the ABI means that PyObject cannot change size, even by adding fields at the end. Right now, the globals representing types are defined like PyAPI_DATA(PyTypeObject) PyList_Type;. To allow the core to use the new type creation functions, it might be useful to make the ABI type objects PyTypeObject* constants instead. In general, this looks really good. Thanks! Jeffrey On Sun, May 17, 2009 at 1:54 PM, Martin v. Löwis mar...@v.loewis.de wrote: Thomas Wouters reminded me of a long-standing idea; I finally found the time to write it down. Please comment! Regards, Martin PEP: 384 Title: Defining a Stable ABI Version: $Revision: 72754 $ Last-Modified: $Date: 2009-05-17 21:14:52 +0200 (So, 17. Mai 2009) $ Author: Martin v. Löwis mar...@v.loewis.de Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17-May-2009 Python-Version: 3.2 Post-History: Abstract Currently, each feature release introduces a new name for the Python DLL on Windows, and may cause incompatibilities for extension modules on Unix. This PEP proposes to define a stable set of API functions which are guaranteed to be available for the lifetime of Python 3, and which will also remain binary-compatible across versions. Extension modules and applications embedding Python can work with different feature releases as long as they restrict themselves to this stable ABI. Rationale = The primary source of ABI incompatibility are changes to the lay-out of in-memory structures. For example, the way in which string interning works, or the data type used to represent the size of an object, have changed during the life of Python 2.x. As a consequence, extension modules making direct access to fields of strings, lists, or tuples, would break if their code is loaded into a newer version of the interpreter without recompilation: offsets of other fields may have changed, making the extension modules access the wrong data. In some cases, the incompatibilities only affect internal objects of the interpreter, such as frame or code objects. For example, the way line numbers are represented has changed in the 2.x lifetime, as has the way in which local variables are stored (due to the introduction of closures). Even though most applications probably never used these objects, changing them had required to change the PYTHON_API_VERSION. On Linux, changes to the ABI are often not much of a problem: the system will provide a default Python installation, and many extension modules are already provided pre-compiled for that version. If additional modules are needed, or additional Python versions, users can typically compile them themselves on the system, resulting in modules that use the right ABI. On Windows, multiple simultaneous installations of different Python versions are common, and extension modules are compiled by their authors, not by end users. To reduce the risk of ABI incompatibilities, Python currently introduces a new DLL name pythonXY.dll for each feature release, whether or not ABI incompatibilities actually exist. With this PEP, it will be possible to reduce the dependency of binary extension modules on a specific Python feature release, and applications embedding Python can be made work with different releases. Specification
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 review versions: +Python 2.7 -Python 2.6 Added file: http://bugs.python.org/file14010/jump_to_firstlineno.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1689458 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to completely capture the current state of affairs. I'm posting this here so that people can check that I got it right. Thanks! I also discovered that we've attached 2 layers of patches to the basic tracing scheme. The first layer avoids jumping to instructions that don't start a line, to avoid problems in if statements and while loops. The second layer discovered that jumps backward do need to trace at instructions that don't start a line, so it added extra lnotab entries for 'while' and 'for' loops, and added a special case for backward jumps within the same line. I replaced these patches by treating forward and backward jumps differently. I could simplify this slightly more by changing PyCode_CheckLineNumber. It doesn't appear to be used outside of the core, but since it doesn't start with an _, I want to double-check that changing its interface is ok. -- components: Interpreter Core files: lnotab.patch keywords: needs review, patch messages: 87919 nosy: jyasskin severity: normal stage: patch review status: open title: Document and slightly simplify lnotab tracing versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file13996/lnotab.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6042 ___ ___ 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.
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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 # Here, sys.exc_info() ought to refer to the inner # exception, but instead it refers to the outer one. try: raise ValueError(outer exception) except ValueError: for i in raising_generator(): pass sys.exc_info gets reset even if there's no outer exception. The attached (failing) patch highlights this problem, and tests other sys.exc_info behavior around function calls. -- components: Interpreter Core files: exc_info.patch keywords: patch messages: 87452 nosy: collinwinter, jyasskin priority: low severity: normal stage: needs patch status: open title: sys.exc_info leaks into a generator type: behavior versions: Python 2.6, Python 2.7, Python 3.1 Added file: http://bugs.python.org/file13927/exc_info.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5970 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. -- assignee: - barry nosy: +barry Added file: http://bugs.python.org/file13928/exc_info_26.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5970 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 know more about the guts of the interpreter than they should need. The proposed PyFrame_GetLineNumber provides a more obvious and direct way to do the same thing. If this goes in, we might be able to deprecate PyCode_Addr2Line entirely. The uses of PyCode_Addr2Line that don't get the line of a particular frame seem to be getting the line from a traceback (for example, http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.cq=PyCode_Addr2Line), which is replaced by the tb_lineno field. -- components: Interpreter Core files: PyFrame_GetLineNumber.patch keywords: needs review, patch messages: 87360 nosy: collinwinter, jyasskin severity: normal stage: patch review status: open title: PyFrame_GetLineNumber type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file13909/PyFrame_GetLineNumber.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 the filename, function name, and first line number, instead of also requiring lots of code internals. -- components: Interpreter Core files: PyCode_NewEmpty.patch keywords: needs review, patch messages: 87385 nosy: collinwinter, jyasskin severity: normal stage: patch review status: open title: PyCode_NewEmpty type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file13913/PyCode_NewEmpty.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5959 ___ ___ 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 jyass...@gmail.com added the comment: Yes, sorry. That was fixed in r69927. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1540386 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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://bugs.python.org/issue5812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
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 those are fixed and tested. I may not get to it for a day or two, so someone else is welcome to update the patch instead. :) -- assignee: pitrou - jyasskin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
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 did anything dumb? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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://bugs.python.org/issue4715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
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 work there. Review at http://codereview.appspot.com/20103 if you like. Performance: 32-bit gcc-4.3 Intel Core2: 2to3: 25.09 - 24.63: 1.87% faster Django: Min: 0.614 - 0.609: 0.86% faster Avg: 0.616 - 0.635: 3.09% slower Pickle: (cPickle) Min: 1.647 - 1.651: 0.21% slower Avg: 1.650 - 1.656: 0.39% slower PyBench: Min: 5341 - 5273: 1.29% faster Avg: 5450 - 5397: 0.98% faster SlowPickle: (pickle) Min: 1.384 - 1.341: 3.13% faster Avg: 1.385 - 1.343: 3.08% faster Spitfire: Min: 0.773 - 0.690: 11.97% faster Avg: 0.776 - 0.695: 11.62% faster Spitfire re-run: Min: 0.740 - 0.693: 6.81% faster Avg: 0.744 - 0.695: 6.93% faster SlowUnpickle: (pickle) Min: 0.645 - 0.668: 3.37% slower Avg: 0.646 - 0.670: 3.59% slower SlowUnpickle re-run: Min: 0.645 - 0.660: 2.31% slower Avg: 0.645 - 0.661: 2.32% slower Unpickle: (cPickle) Min: 1.015 - 1.006: 0.89% faster Avg: 1.021 - 1.009: 1.16% faster 64-bit gcc-4.3 Intel Core2 2to3: 22.31 - 21.97: 1.57% faster Django: Min: 0.577 - 0.564: 2.29% faster Avg: 0.579 - 0.566: 2.20% faster Pickle: Min: 1.162 - 1.178: 1.35% slower Avg: 1.166 - 1.183: 1.37% slower PyBench: Min: 4498 - 4193: 7.27% faster Avg: 4586 - 4276: 7.25% faster SlowPickle: Min: 1.212 - 1.133: 6.92% faster Avg: 1.213 - 1.135: 6.92% faster Spitfire: Min: 0.631 - 0.617: 2.32% faster Avg: 0.632 - 0.621: 1.75% faster SlowUnpickle: Min: 0.575 - 0.551: 4.31% faster Avg: 0.576 - 0.553: 4.14% faster Unpickle: Min: 0.708 - 0.722: 1.88% slower Avg: 0.745 - 0.736: 1.20% faster -- assignee: - pitrou Added file: http://bugs.python.org/file13227/trunk-opt-loop.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 without going through a relative jump or a fallthrough. The patch is also #2 at http://codereview.appspot.com/20064. I'll post performance numbers as soon as I've measured them. Added file: http://bugs.python.org/file13182/trunk-opt-cond-jump.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: 1.424 - 1.376: 3.48% faster
Avg: 1.427 - 1.378: 3.55% faster
Spitfire:
Min: 0.701 - 0.718: 2.32% slower
Avg: 0.710 - 0.721: 1.47% slower
Unpickle:
Min: 0.667 - 0.651: 2.33% faster
Avg: 0.668 - 0.652: 2.38% faster
Intel Core 2, gcc-4.3, 64-bit
2to3:
22.40 - 22.59: 0.81% slower
Django:
Min: 0.575 - 0.565: 1.74% faster
Avg: 0.577 - 0.567: 1.76% faster
PyBench:
Min: 4332 - 4433: 2.28% slower
Avg: 4393 - 4519: 2.79% slower
Pickle:
Min: 1.177 - 1.204: 2.25% slower
Avg: 1.180 - 1.205: 2.14% slower
Spitfire:
Min: 0.622 - 0.629: 1.22% slower
Avg: 0.623 - 0.631: 1.26% slower
Unpickle:
Min: 0.576 - 0.563: 2.25% faster
Avg: 0.596 - 0.564: 5.55% faster
On my MacBook, gcc-4.0, 32-bit:
2to3:
29.82 - 29.39: 1.46% faster
Django:
Min: 0.727 - 0.720: 0.98% faster
Avg: 0.746 - 0.736: 1.45% faster
PyBench:
Min: 6303 - 6432: 2.01% slower
Avg: 6471 - 6563: 1.40% slower
Pickle:
Min: 1.564 - 1.564: 0.00% faster
Avg: 1.609 - 1.592: 1.07% faster
Spitfire:
Min: 0.902 - 0.909: 0.78% slower
Avg: 0.924 - 0.920: 0.41% faster
Unpickle:
Min: 0.784 - 0.763: 2.73% faster
Avg: 0.794 - 0.776: 2.26% faster
The performance isn't as good as I'd like, especially on 64-bits. I
suspect the difference from the py3k branch is that trunk doesn't have
Antoine's dispatch patch, and POP_TOP is predicted after
JUMP_IF_{TRUE,FALSE}, which means without computed-goto-dispatch, this
patch usually only saves a predictable if(). The skipped JUMP_ABSOLUTEs
may not happen enough in my benchmarks to matter much.
On the other hand, ./python.exe -m timeit -s 'x=range(500)' '[y+3 for y
in x if y%5 2]' shows the following differences on my MacBook
For py3k:
Min: 196.000 - 172.000: 13.95% faster
Avg: 200.000 - 178.600: 11.98% faster
Significant (t=5.339997, a=0.95)
For trunk:
Min: 108.000 - 88.200: 22.45% faster
Avg: 114.571 - 97.571: 17.42% faster
Significant (t=5.518236, a=0.95)
That list comprehension definitely takes advantage of skipping the
JUMP_ABSOLUTE.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4715
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 it into the issue 2459 patch, and then committing that patch. Let me know if that's crazy. http://codereview.appspot.com/20064 Added file: http://bugs.python.org/file13170/condbranches-plus2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 is in the documentation. Trade away speed for Py3k compat warnings is a bit harsh for a 1.5% penalty. How about Define to get Py3k compatibility warnings at the cost of a little speed? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5362 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 http://bugs.python.org/issue4715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 for % operations. Probably, given that there's an indirect call in the way, the extra test would hide in the noise, but it's worth checking. What's a good numeric benchmark suite? `time ./python Lib/test/test_decimal.py`? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5176 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-gcse actually does it, and in my brief tests, the manual is actually correct (compiling with just -fno-crossjumping combined gotos anyway). Otherwise, threadedceval6.patch looks good to submit to me. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 __slots__ (or I'd have known that just defining it on Fraction wouldn't work :-/) but if it doesn't prevent subclasses from having dicts, it seems like a good idea to add an empty __slots__ to most classes in the ABC hierarchy, and definitely the numeric ones. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 #if the definitions of Py_LIKELY and Py_UNLIKELY instead of __builtin_expect so new compilers can easily add their own definitions. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4941 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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); /* These two values aren't handled in the
loop. */
assert(why != WHY_RERAISE);
orig_why = why;
while (why != WHY_NOT f-f_iblock 0) {
/* The code does not change 'why' without breaking out of the loop. */
assert(why == orig_why);
...
}
which would tell the reader more about the state of the world without
focusing their attention on anything that isn't somehow special.
Of course, nothing prevents the code from changing orig_why (*pines for
const and late declarations*), but such a change would be more obviously
wrong.
Was there another reason to assert(why!=WHY_YIELD) than that the if's
don't handle it? Is 'why' more likely to become WHY_YIELD than WHY_RERAISE?
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4888
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 and JUMP_IF_TRUE_OR_POP (or s/OR/ELSE/)? If the old opcodes weren't called JUMP_IF_XXX, I'd suggest the always-popping variants just use those names. Many other opcodes implicitly consume their arguments so these could too. But since this would be confusing with both the old meanings and the other new pair, your names are probably better. The comments in opcode.h and opcode.py are inconsistent. I now get a warning that PRED_POP_TOP is defined but not used, so you should remove the PREDICTED macro for it. I wonder if BINARY_AND and BINARY_OR should get predictions ... not for this patch. I would probably put the POP_JUMP_IF_XXX definitions next to the JUMP_OR_POP definitions to emphasize their similarity. You missed a comment referring to JUMP_IF_FALSE before compiler_try_except(). POP_JUMP_IF_TRUE is only used in one place: assertions. I wonder if anyone would cry if we compiled assertions to UNARY_NOT; POP_JUMP_IF_FALSE instead... Anyway, also not for this patch. In compiler_comprehension_generator, compiler_use_next_block(c, skip); is now always followed by compiler_use_next_block(c, if_cleanup);. Should you remove the use(skip) call? In peephole.c, s/JUMP_SIGN/JUMPS_ON_TRUE/ ? test_peepholer fails for me, which makes sense because it still refers to JUMP_IF_XXX. Whoo, the peephole.c changes are complex. I'll do those in a second round. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. I'll look over threadedceval5.patch in detail next. Added file: http://bugs.python.org/file12705/vmgen_2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 have come up with a couple ideas to get around that. Replication would be trickier since we want the bytecode generation to be deterministic, but it's probably doable too. I'll post any significant results I get. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 patch (representing forth-style dispatch) a bit so that it passes all the tests, and on the same machine it got a 13%-17% speedup. The vmgen patch is not quite at feature parity (it throws out support for LLTRACE and a couple other #defines), and there are fairly good arguments against committing it to python at all (it requires installing and modifying vmgen to build), but I'll post it after I've ported it to trunk. Re skip and paolo: JITting and machine-specific assembly will probably be important to speeding up Python in the long run, but they'll also take a long while to get right, so we shouldn't let them distract us from committing the dispatch optimization. Added file: http://bugs.python.org/file12687/pitrou_dispatch_2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 in socketmodule.c:socket_gethostbyaddr(), but llvm-gcc (possibly only HEAD, not 2.4) does not, which causes a segfault in test_socket.py. The llvm bug investigating the problem is http://llvm.org/bugs/show_bug.cgi?id=3233. The attached patch specifies the alignment so that llvm-gcc and unfixed glibcs work together. I'll commit this tomorrow if there are no objections. -- components: Extension Modules files: fix_gethostbyaddr.patch keywords: patch messages: 79429 nosy: collinwinter, jyasskin severity: normal stage: patch review status: open title: Work around gethostbyaddr_r bug type: crash versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12654/fix_gethostbyaddr.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4884 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, -1) ought to return an int. Making that change would be slightly backwards-incompatible, but IIRC, int is supposed to be usable everywhere float is, so there should be very few programs it would break. So my vote's to change it, for 3.0.1 if possible. The documentation is a little too strict on __round__ implementations by requiring round(x, y) to return the same type as x, but I think it should still encourage __round__ to return the same type. And, uh, oops for writing those bugs. Is your guess for round(25.0, -1)==30.0 that 25.0*(1/10.0) is slightly more than 2.5 on some systems? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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://bugs.python.org/issue4477 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue4597 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 there. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4589 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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! -- keywords: -needs review resolution: - accepted stage: patch review - commit review ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4589 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. -- assignee: jyasskin components: Interpreter Core files: fix_exceptions.patch keywords: needs review, patch messages: 77332 nosy: jyasskin priority: normal severity: normal stage: patch review status: open title: EvalFrameEx fails to set 'why' for some exceptions type: behavior versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12286/fix_exceptions.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4597 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 = exit_result ... def __enter__(self): ... return 3 ... def __exit__(self, a, b, c): ... return self.exit_result() ... class TrueAsBool(object): ... def __nonzero__(self): return True ... class FalseAsBool(object): ... def __nonzero__(self): return False ... class FailAsBool(object): ... def __nonzero__(self): ... raise RuntimeError(Should see this but won't) ... with CM(TrueAsBool): ... raise AssertionError(Should NOT see this) ... with CM(FalseAsBool): ... raise AssertionError(Should see this) ... Traceback (most recent call last): File stdin, line 2, in module AssertionError: Should see this with CM(FailAsBool): ... raise AssertionError(Should see RuntimeException (oops)) ... The problem is that WITH_CLEANUP only checks if PyObject_IsTrue(x) returns non-zero, but that function returns 0 when the bool conversion raises an exception. -- assignee: jyasskin components: Interpreter Core messages: 77290 nosy: jyasskin severity: normal stage: needs patch status: open title: 'with' loses -bool exceptions type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4589 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 review - committed/rejected ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4477 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 [EMAIL PROTECTED] http://bugs.python.org/issue4477 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 this speedup on their machines? I'm running on a Macbook Pro (Intel Core2 processor, probably Merom) with a 32-bit build from Apple's gcc-4.0.1. (Apple's gcc consistently produces a faster python than gcc-4.3.) 2) Assuming this speeds things up for most people, should I check it in anywhere besides the trunk? I assume it's out for 3.0; is it in for 2.6.1 or 3.0.1? Pybench output: --- PYBENCH 2.0 --- * using CPython 2.7a0 (trunk:67458M, Nov 30 2008, 17:14:10) [GCC 4.0.1 (Apple Inc. build 5488)] * disabled garbage collection * system check interval set to maximum: 2147483647 * using timer: time.time --- Benchmark: pybench.out --- Rounds: 10 Warp: 10 Timer: time.time Machine Details: Platform ID:Darwin-9.5.0-i386-32bit Processor: i386 Python: Implementation: CPython Executable: /Users/jyasskin/src/python/trunk-fast-tracing/build/python.exe Version:2.7.0 Compiler: GCC 4.0.1 (Apple Inc. build 5488) Bits: 32bit Build: Nov 30 2008 17:14:10 (#trunk:67458M) Unicode:UCS2 --- Comparing with: ../build_orig/pybench.out --- Rounds: 10 Warp: 10 Timer: time.time Machine Details: Platform ID:Darwin-9.5.0-i386-32bit Processor: i386 Python: Implementation: CPython Executable: /Users/jyasskin/src/python/trunk-fast-tracing/build_orig/python.exe Version:2.7.0 Compiler: GCC 4.0.1 (Apple Inc. build 5488) Bits: 32bit Build: Nov 30 2008 13:51:09 (#trunk:67458) Unicode:UCS2 Test minimum run-timeaverage run-time thisother diffthisother diff --- BuiltinFunctionCalls: 127ms 130ms -2.4% 129ms 132ms -2.1% BuiltinMethodLookup:90ms93ms -3.2%91ms94ms -3.1% CompareFloats:88ms91ms -3.3%89ms93ms -4.3% CompareFloatsIntegers:97ms99ms -2.1%97ms 100ms -2.4% CompareIntegers:79ms82ms -4.2%79ms85ms -6.1% CompareInternedStrings:90ms92ms -2.4%94ms94ms -0.9% CompareLongs:86ms83ms +3.6%87ms84ms +3.5% CompareStrings:80ms82ms -3.1%81ms83ms -2.3% CompareUnicode: 103ms 105ms -2.3% 106ms 108ms -1.5% ComplexPythonFunctionCalls: 139ms 137ms +1.3% 140ms 139ms +0.1% ConcatStrings: 142ms 151ms -6.0% 156ms 154ms +1.1% ConcatUnicode:87ms92ms -5.4%89ms94ms -5.7% CreateInstances: 142ms 144ms -1.4% 144ms 145ms -1.1% CreateNewInstances: 107ms 109ms -2.3% 108ms 111ms -2.1% CreateStringsWithConcat: 114ms 137ms -17.1% 117ms 139ms -16.0% CreateUnicodeWithConcat:92ms 101ms -9.2%95ms 102ms -7.2% DictCreation:77ms81ms -4.4%80ms85ms -5.9% DictWithFloatKeys:91ms 107ms -14.5%93ms 109ms -14.6% DictWithIntegerKeys:95ms94ms +1.4% 108ms96ms +12.3% DictWithStringKeys:83ms88ms -5.8%84ms88ms -4.7% ForLoops:72ms72ms -0.1%79ms74ms +5.8% IfThenElse:83ms80ms +3.9%85ms80ms +5.3% ListSlicing: 117ms 118ms -0.7% 118ms 121ms -1.8% NestedForLoops: 116ms 119ms -2.4% 121ms 121ms +0.0% NormalClassAttribute: 106ms 115ms -7.7% 108ms 117ms -7.7% NormalInstanceAttribute:96ms98ms -2.3%97ms 100ms -3.1% PythonFunctionCalls:92ms95ms -3.7%94ms99ms -5.2% PythonMethodCalls: 147ms 147ms +0.1% 152ms 149ms +2.1% Recursion: 135ms 136ms -0.3% 140ms 144ms -2.9% SecondImport: 101ms99ms +2.1% 103ms 101ms +2.2
[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
[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
[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 the decimal maintainers decide. -- nosy: +rhettinger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2748 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 is interrupted. So my inclination would be to let EINTR be raised in the first case, and use a loop to handle it in the second. Regarding the patch, a wrapper function called as retry_on_eintr(obj.write, data) might be a cleaner way to do it. -- nosy: +jyasskin _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1068268 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 that the object has been destroyed. I don't know the exception handling code very well, so I'd like someone more familiar with it to check that the patch is correct and efficient. Collin, would you do the honors? -- assignee: - collinwinter nosy: +collinwinter __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2507 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 counting references will fix it nearly every time, but I'd like to kill the race dead if we can. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2496 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
