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