[issue4939] Failures in test_xmlrpc

Kristján Valur Jónsson added the comment: Ok, I'll keep them disabled until I figure out why they take so long. Maybe there is some performance enhancements yet to be made :) ___ Python tracker ___

[issue4940] decimal.Decimal.__init__ should raise an instance of ValueError

New submission from rech : A common pattern is to check numeric input like this: a = input() try: int(a) # or float(a) except ValueError: print("Bad input") One would expect this to work with decimal.Decimal(a), too. But, as Decimal.__init__ raises decimal.InvalidOperation instead of a Va

[issue1565525] gc allowing tracebacks to eat up memory

STINNER Victor added the comment: I wrote a patch to support .tb_frame=None. It works but the traceback becomes useless because you have unable to display the traceback. The frame is used by tb_printinternal() to get the filename (co_filename) and the code name (co_name). I also tried: w

[issue4940] decimal.Decimal.__init__ should raise an instance of ValueError

Raymond Hettinger added the comment: Sorry, the decimal world has it's own little world of precisely defined and spec-mandated exceptions. -- nosy: +rhettinger ___ Python tracker ___

[issue1565525] gc allowing tracebacks to eat up memory

Greg Hazel added the comment: But a list of strings is not re-raisable. The co_filename, co_name, and such used to print a traceback are not dependent on the locals or globals. ___ Python tracker __

[issue1565525] gc allowing tracebacks to eat up memory

STINNER Victor added the comment: I tried to remove the frame from the traceback type (to keep only the filename and code name), but many functions rely on the frame object. Some examples: Lib/unittest.py: class TestResult(object): def _is_relevant_tb_level(self, tb): return

[issue1565525] gc allowing tracebacks to eat up memory

STINNER Victor added the comment: Greg Hazel> But a list of strings is not re-raisable Do you need the original traceback? Why not only raising the exception? Eg. import sys try: raise Exception("hm!") except: t, v, tb = sys.exc_info() raise v

[issue1565525] gc allowing tracebacks to eat up memory

Greg Hazel added the comment: STINNER Victor> Do you need the original traceback? Why not only raising the exception? If the exception was captured in one stack, and is being re-raised in another. It would be more useful to see the two stacks appended instead of just the place where it was r

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

New submission from Daniel Diniz : As suggested by Paolo Giarrusso, add a "likely()" to Py_DECREF, telling GCC it doesn't call the destructor in the common path. This optimization seems to interact well with #4896 and to be slower on top of #4753 on my system. Patching ceval.c instead of object.

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

Antoine Pitrou added the comment: I get a slowdown here (results attached). Many objects are shortlived in Python, so I'm not sure the approach is valid anyway. Added file: http://bugs.python.org/file12732/pybench.txt ___ Python tracker

[issue4715] optimize bytecode for conditional branches

Jeffrey Yasskin 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/)?

[issue4715] optimize bytecode for conditional branches

Raymond Hettinger added the comment: FWIW, the goal is to replace the opcode peephole optimizer with a more powerful equivalent working on the AST just prior to code generation. -- nosy: +rhettinger ___ Python tracker

[issue4942] accept() on AF_UNIX sockets broken on arm as of 2.5.3

New submission from Hamish Moffatt : As of 2.5.3, calling accept() on an AF_UNIX socket fails on arm. The following exception occurs: SystemError: Negative size passed to PyString_FromStringAndSize I have attached a test program that creates a socket and connects to it. It works on x86-64 but f

[issue4943] trace.CoverageResults.write_results can't write results file for modules loaded by __path__ manipulation

New submission from Matt McClure : The function trace.CoverageResults.write_results() can't write coverage results on Windows for modules loaded by using the __path__ feature of PEP 302. For example, Bazaar uses the __path__ feature to load plugins from directories specified by the BZR_PLUGIN_PA

[issue4940] decimal.Decimal.__init__ should raise an instance of ValueError

Changes by Benjamin Peterson : -- resolution: -> rejected status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue4943] trace.CoverageResults.write_results can't write results file for modules loaded by __path__ manipulation

Matt McClure added the comment: The attached patch replaces the offending colon with a period. -- keywords: +patch Added file: http://bugs.python.org/file12735/tracebug.patch ___ Python tracker

[issue4933] Patch to add preliminary support for Haiku

Alexander Belopolsky added the comment: > we decided some time ago to not accept patches for such minority > platforms anymore. I don't have any particular interest in BeOS variants, but this comes as a surprise given that http://python.org/about/ proclaims that "Python runs everywhere." Ma

[issue4944] os.fsync() doesn't work as expect in Windows

New submission from Javen Wang : I encountered a very strange issue in file flush operation in Windows. Here's the scenario of my application: 1. The main thread of my application will create makefiles sequentially. 2. Once a makefile is generated, launch a separate process calling nmake

[issue1519638] Unmatched Group issue - workaround

Gerard added the comment: Dear Bobby, I don't see what would be the part that generates the empty string? Regards, Gerard. ___ Python tracker ___ ___

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

Paolo 'Blaisorblade' Giarrusso added the comment: If speedup on other machines are confirmed, a slowdown of less than 2% should be acceptable (it's also similar to the statistic noise I have on my machine - it's a pity pybench does not calculate the standard deviation of the execution time). It

[issue4945] json checks True/False by identity, not boolean value

New submission from Gabriel Genellina : json compares arguments against True/False by identity, not by boolean value; by example: if (skipkeys is False and ensure_ascii is True and check_circular is True and allow_nan is True ... Using `ensure_ascii=1` won't work as intended. I don

[issue4945] json checks True/False by identity, not boolean value

Changes by Gabriel Genellina : -- keywords: +patch Added file: http://bugs.python.org/file12736/json.diff ___ Python tracker ___ ___ Py

[issue4715] optimize bytecode for conditional branches

Jeffrey Yasskin added the comment: In peephole.c: _optimize isn't a great label name, but I don't have a great replacement. Maybe reoptimize_current_index? Your change to the "LOAD_CONST trueconst JUMP_IF_FALSE xx POP_TOP" optimization doesn't preserve the optimization to: def f(): retur

[issue4944] os.fsync() doesn't work as expect in Windows

Changes by Ulrich Eckhardt : -- nosy: +eckhardt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

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

Martin v. Löwis added the comment: I dislike about this patch that there are two different else cases (giving the trivial macro definition); there should only be one such case. -- nosy: +loewis ___ Python tracker _

[issue4753] Faster opcode dispatch on gcc

Paolo 'Blaisorblade' Giarrusso added the comment: #4715 is interesting, but is not really about superinstructions. Superinstructions are not created because they make sense; any common sequence of opcodes can become a superinstruction, just for the point of saving dispatches. And the creation ca

[issue4942] accept() on AF_UNIX sockets broken on arm as of 2.5.3

Martin v. Löwis added the comment: No further bug fixes are accepted for Python 2.5. Closing this as "won't fix". -- nosy: +loewis resolution: -> wont fix status: open -> closed ___ Python tracker

[issue4933] Patch to add preliminary support for Haiku

Martin v. Löwis added the comment: > I don't have any particular interest in BeOS variants, but this comes as > a surprise given that http://python.org/about/ proclaims that "Python > runs everywhere." > > Maybe Haiku could become a supported platform instead of more or less > defunct BeOS?

[issue4944] os.fsync() doesn't work as expect in Windows

Gabriel Genellina added the comment: I tried to reproduce the issue, interpreting your description, but failed. It worked fine in my setup. Perhaps you can add more elements until it fails. -- nosy: +gagenellina Added file: http://bugs.python.org/file12737/test_file_flush.py

[issue4944] os.fsync() doesn't work as expect in Windows

Changes by Gabriel Genellina : Added file: http://bugs.python.org/file12738/checkfile.c ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue4942] accept() on AF_UNIX sockets broken on arm as of 2.5.3

Hamish Moffatt added the comment: Thanks for your feedback, but I'm a bit confused by the note on the web site: "This is the last bugfix release of Python 2.5. Python 2.5 is now in bugfix-only mode; no new features are being added." This implies further bug fixes are possible (and further fixe

[issue4942] accept() on AF_UNIX sockets broken on arm as of 2.5.3

Martin v. Löwis added the comment: > "This is the last bugfix release of Python 2.5. Python 2.5 is now in > bugfix-only mode; no new features are being added." Thanks for pointing that out; I have fixed the page now. > Also it's a regression from 2.5.2, which must be of some concern? It is; a

[issue4944] os.fsync() doesn't work as expect in Windows

Amaury Forgeot d'Arc added the comment: python2.5 uses the functions of the fopen() family: fwrite(), fclose(). Does the problem reproduce if you use these functions in your extension module? Are your files located on the local hard drive, or on a network storage? -- nosy: +amaury.fo

[issue4942] accept() on AF_UNIX sockets broken on arm as of 2.5.3

Hamish Moffatt added the comment: Understood. Would it be appropriate to list this issue on the known bugs page? http://www.python.org/download/releases/2.5.4/bugs/ I can't reproduce it on x86, but it's probably not ARM specific. It might even be a compiler bug. I tried the same version on x86

<    1   2