[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

[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

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

[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

[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

[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

[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?

[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

[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

[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 _

[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

[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

[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

[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

[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

[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 ___ ___

[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

[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

[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

[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

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

[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

[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

[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/)?

[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

[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.

[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

[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

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

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 __

[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

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

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

[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 ___

[issue4939] Failures in test_xmlrpc

Benjamin Peterson added the comment: On Tue, Jan 13, 2009 at 6:11 PM, Kristján Valur Jónsson wrote: > > Kristján Valur Jónsson added the comment: > > Yes and they work, but do take some 10 seconds to run. If it is > similar on unix, I'll do so. What's your numbers? It takes about a second t

[issue4939] Failures in test_xmlrpc

Kristján Valur Jónsson added the comment: Yes and they work, but do take some 10 seconds to run. If it is similar on unix, I'll do so. What's your numbers? ___ Python tracker ___ _

[issue2723] Truncate __len__() at sys.maxsize

STINNER Victor added the comment: Initial proposition (len.diff) was rejected. If you want to change len() behaviour, reopen this issue or open another one. -- resolution: -> rejected status: open -> closed ___ Python tracker

[issue4939] Failures in test_xmlrpc

Benjamin Peterson added the comment: On Tue, Jan 13, 2009 at 5:52 PM, Kristján Valur Jónsson wrote: > > Kristján Valur Jónsson added the comment: > > Ok, you beat me to it. Sorry, I just seem to have bad timing today. :) > So, is there any good reason to keep those xmlrpc tests defunct on >

[issue4939] Failures in test_xmlrpc

Kristján Valur Jónsson added the comment: Ok, you beat me to it. So, is there any good reason to keep those xmlrpc tests defunct on win32 still? ___ Python tracker ___ __

[issue4939] Failures in test_xmlrpc

Benjamin Peterson added the comment: Fixed in r68597. -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue4715] optimize bytecode for conditional branches

Antoine Pitrou added the comment: > http://code.google.com/p/spitfire/. It's a template system designed > for performance that I have some experience with. 6% faster on a template system simply by optimizing conditional jumps is quite neat. (the spitfire homepage itself is rather intriguing, th

[issue4899] doctest should support fixtures

Alexander Belopolsky added the comment: The OP's problem, i.e. the need to reimport modules in every docstring can easily be addressed by injecting the necessary names using extraglobs argument to doctest.testmod(). I like the following trick: def getextraglobs(): import StringIO, tempfi

[issue4939] Failures in test_xmlrpc

Kristján Valur Jónsson added the comment: Oh dear, this is because it skips those tests on windows. I'll check in a fix to xmlrpclib.py ___ Python tracker ___ __

[issue2736] datetime needs and "epoch" method

Changes by STINNER Victor : Removed file: http://bugs.python.org/file12123/timestamp.py ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue2736] datetime needs and "epoch" method

Changes by STINNER Victor : Removed file: http://bugs.python.org/file12014/datetime_totimestamp-2.patch ___ Python tracker ___ ___ Python-bugs-

[issue2736] datetime needs and "epoch" method

Changes by STINNER Victor : Removed file: http://bugs.python.org/file12013/datetime_totimestamp.patch ___ Python tracker ___ ___ Python-bugs-li

[issue1162154] inspect.getmembers() breaks sometimes

Amaury Forgeot d'Arc added the comment: Fixed in r68596. -- nosy: +amaury.forgeotdarc resolution: -> fixed status: open -> closed ___ Python tracker ___ _

[issue4804] Python on Windows disables all C runtime library assertions

Kristján Valur Jónsson added the comment: It is not an issue with debug builds only. The crt error handler is currently also reset globally for all builds which is very evil. The current way we do thing is also not thread safe WRT other application threads. On second thought though it is be

[issue4939] Failures in test_xmlrpc

STINNER Victor added the comment: r68532 was a fix for the issue #4879 and removed an old compatibility interface (_parse_response). ___ Python tracker ___ __

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

John Levon added the comment: Yes, Python guarantees the behaviour under discussion: http://docs.python.org/library/signal.html ___ Python tracker ___ ___

[issue4939] Failures in test_xmlrpc

STINNER Victor added the comment: Regression introduced by r68532. Replace self._parse_response() by self.parse_response() fixes the tests. -- nosy: +haypo ___ Python tracker __

[issue4715] optimize bytecode for conditional branches

Antoine Pitrou added the comment: Sorry, hadn't seen your message before removing the file. Here it is again. Added file: http://bugs.python.org/file12730/condbranches.patch ___ Python tracker _

[issue4929] smptlib.py can raise socket.error

Kristján Valur Jónsson added the comment: If you can offer a suggestion as to how to reliably trigger a WSAECONNRESET error on windows (or its equivalent on unix) I'll be happy to do that. ___ Python tracker _

[issue4715] optimize bytecode for conditional branches

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file12419/condbranches.patch ___ Python tracker ___ ___ Python-bugs-list maili

[issue4927] Inconsistent unicode repr for fileobject

Kristján Valur Jónsson added the comment: Turns out it wasn't vista related at all, but related to TESTFN being t...@test When this happens, test_file.py fails when testing the repr for a unicode file, because the repr contains u'tm...@test' whereas for a string filename it will contain 't...

[issue4715] optimize bytecode for conditional branches

Collin Winter added the comment: On Tue, Jan 13, 2009 at 3:25 PM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Hello, > >> I've backported condbranches-plus.patch to trunk, and I'm getting these >> results: > > Thanks! > >> PyBench: 1.84-2.21% faster >> 2to3: 3.83% faster >>

[issue4939] Failures in test_xmlrpc

Changes by Antoine Pitrou : -- nosy: +krisvale ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue4935] Segmentation fault in bytearray tests

Antoine Pitrou added the comment: Committed in trunk, py3k, 2.6 and 3.0. Thanks! -- resolution: accepted -> fixed status: open -> closed ___ Python tracker ___ __

[issue4715] optimize bytecode for conditional branches

Antoine Pitrou added the comment: Hello, > I've backported condbranches-plus.patch to trunk, and I'm getting these > results: Thanks! > PyBench: 1.84-2.21% faster > 2to3: 3.83% faster > Spitfire: 6.13-6.23% faster What is Spitfire? > I've haven't tested condbranches.patch vs condbranches-p

[issue4871] zipfile can't decrypt

STINNER Victor added the comment: Patch for py3k: str=>bytes, remove "u" string prefix and rename "bytes" variable to "data" to avoid conflict with the bytes type. Added file: http://bugs.python.org/file12729/zipfile_no_unicode_pasword-2-py3k.patch ___ Py

[issue4939] Failures in test_xmlrpc

New submission from Antoine Pitrou : This is witnessed on trunk, at home as well as on the buildbots: == ERROR: test_dotted_attribute (test.test_xmlrpc.SimpleServerTestCase) --

[issue4871] zipfile can't decrypt

STINNER Victor added the comment: gagenellina: Oops, yes, I wrote my patch for Python trunk. New patch only uses two checks for the password type (since extract() calls open()). I also changed the error message. -- versions: +Python 2.6, Python 2.7, Python 3.1 Added file: http://bugs.

[issue4715] optimize bytecode for conditional branches

Collin Winter added the comment: I've backported condbranches-plus.patch to trunk, and I'm getting these results: PyBench: 1.84-2.21% faster 2to3: 3.83% faster Spitfire: 6.13-6.23% faster PyBench was run with -w=1; 2to3 is translating its entire source directory five times; Spitfire is measu

[issue4807] wrong wsprintf usage

Amaury Forgeot d'Arc added the comment: Fixed in r68592. -- resolution: accepted -> fixed status: open -> closed ___ Python tracker ___ __

[issue4899] doctest should support fixtures

Changes by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue4938] Pdb cannot access doctest source in postmortem

New submission from Alexander Belopolsky : With attached x.py: $ cat x.py """ >>> foo() """ def foo(): 1/0 if __name__ == '__main__': import doctest, pdb try: doctest.testmod(raise_on_error=True) except doctest.UnexpectedException, e: pdb.post_mortem(e.exc_info[2

[issue4804] Python on Windows disables all C runtime library assertions

Martin v. Löwis added the comment: > Would you be happier if this functionality was exposed via _msvcrt and > disabled in the test suite (either globally or selectively)? Obviously > this is still not thread-safe, but it is closer towards putting this > behaviour in the control of the app its

[issue4935] Segmentation fault in bytearray tests

Mark Dickinson added the comment: Looks fine; I think this should be applied. It seems as though your reindentation left trailing whitespace on the blank lines in the function: the svn commit hook might complain about this... -- resolution: -> accepted _

[issue4871] zipfile can't decrypt

Gabriel Genellina added the comment: Yes, the unicode flag is irrelevant to the password. To successfuly decrypt a file, one must know the password *and* the encoding in use when it was written, so the only sensible thing to do is to accept bytes only. Your patch looks good to me with a few

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

Antoine Pitrou added the comment: Is there any reason not to simply catch KeyboardInterrupt in the user thread, and then notify the main thread? -- nosy: +pitrou ___ Python tracker _

[issue4804] Python on Windows disables all C runtime library assertions

Mark Hammond added the comment: Martin, Would you be happier if this functionality was exposed via _msvcrt and disabled in the test suite (either globally or selectively)? Obviously this is still not thread-safe, but it is closer towards putting this behaviour in the control of the app itself

[issue4935] Segmentation fault in bytearray tests

Antoine Pitrou added the comment: You are right, old_i and old_j are unused, they were part of another approach I tried and which failed. Attaching new patch with these 2 variables removed, and the function cleanly reindented (of course the patch is messier because of this). Added file: http://

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

John Levon added the comment: This issue also affects Solaris (and in particular xend is broken). Is there a reason bamby's fix isn't yet applied? -- nosy: +movement title: signals in thread problem -> signals not always delivered to main thread, since other threads have the signal unm

[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail

Changes by Roumen Petrov : Added file: http://bugs.python.org/file12725/py-issue-2233.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue4935] Segmentation fault in bytearray tests

Mark Dickinson added the comment: Actually, what's the purpose of old_j? It looks like that's not needed any more, either! ___ Python tracker ___ ___

[issue4935] Segmentation fault in bytearray tests

Mark Dickinson added the comment: What's the purpose of old_i? It looks like it's never used for anything. Other than than, the patch looks good to me. I'd guess that the "if (i < 0)" was simply optimized away. This isn't necessarily a compiler bug: if I understand correctly, a strict readi

[issue4936] bytearrayobject.o does not depend on stringlib files

Benjamin Peterson added the comment: Fixed in r68579 (trunk) and r68581 (py3k). -- nosy: +benjamin.peterson resolution: -> fixed status: open -> closed ___ Python tracker ___ __

[issue4933] Patch to add preliminary support for Haiku

Martin v. Löwis added the comment: > What is the purpose of this patch? I.e. why are you submitting it to > this bug tracker? > > "This patch adds preliminary support for Haiku." In case you were > wondering what Haiku was, it is the open source replacement for BeOS, > see haiku-os.org for more

[issue4933] Patch to add preliminary support for Haiku

Scott McCreary added the comment: On Tue, Jan 13, 2009 at 10:27 AM, STINNER Victor wrote: > > STINNER Victor added the comment: > > Python 2.5 branch is now frozen: only security fixes are accepted. You > should work on 2.6 or better on Python trunk for faster integration of > your patches ;-)

[issue4937] Mac DMG install missing version.plist required by bundlebuilder.py

New submission from Barry Alan Scott : I installed mac python 2.6.1 on Mac OS X 10.5.6 I then ran my pysvn workbench kitting script that uses bundlebuilder.py. It fails because version.plist is not installed. Traceback (most recent call last): File "make_wb_bundle.py", line 91, in myapp.

[issue4242] Classify language vs. impl-detail tests, step 1

Nick Coghlan added the comment: Physically splitting the code base? Ick... I'd prefer just to flag the parts of the test suite that are optional and let the developers of other implementations pick and choose as to how much of the pure Python code they want to adopt to pass the non-optional part

[issue4935] Segmentation fault in bytearray tests

Antoine Pitrou added the comment: Here is a patch. The idea is to use unsigned arithmetic instead of signed, and to check for overflows by comparing with PY_SSIZE_T_MAX. (the exact reason of the crash is unknown, it looks like either a compiler bug or a mis-optimization as (i < 0) returns 0 whi

[issue4871] zipfile can't decrypt

Changes by STINNER Victor : Added file: http://bugs.python.org/file12723/zipfile_no_unicode_pasword.patch ___ Python tracker ___ ___ Python-bug

[issue4871] zipfile can't decrypt

Changes by STINNER Victor : Removed file: http://bugs.python.org/file12722/zipfile_no_unicode_pasword.patch ___ Python tracker ___ ___ Python-b

[issue4871] zipfile can't decrypt

STINNER Victor added the comment: I created small archive with a password using zip 2.32 (Ubuntu Gutsy). The unicode flag is not set and so ASCII charset is used to encode the password. But my password was an unicode password using non-ASCII characters and so I get an UnicodeEncodeError ('asc

[issue4936] bytearrayobject.o does not depend on stringlib files

New submission from Antoine Pitrou : Modifying one of the stringlib files does not trigger recompiling of Objects/bytearray.c, although the latter includes the former. -- components: Build messages: 79770 nosy: pitrou priority: normal severity: normal status: open title: bytearrayobject.

[issue4931] distutils does not show any error msg when can't build C module extensions due to a missing C compiler

Giampaolo Rodola' added the comment: Currently I haven't any C compiler installed on my system so I expect distutils to report that every time I try to compile a C module extension. Python 2.5 did that while Python 2.6 does not. ___ Python tracker

[issue4933] Patch to add preliminary support for Haiku

Martin v. Löwis added the comment: What is the purpose of this patch? I.e. why are you submitting it to this bug tracker? -- nosy: +loewis ___ Python tracker ___

[issue4931] distutils does not show any error msg when can't build C module extensions due to a missing C compiler

Martin v. Löwis added the comment: What is the specific error you are reporting? -- nosy: +loewis ___ Python tracker ___ ___ Python-bu

[issue4935] Segmentation fault in bytearray tests

New submission from Antoine Pitrou : This happens on a 32-bit build on a 64-bit system, which happens to have some interesting properties: for example, malloc() will happily allocate memory larger than Py_SSIZE_T_MAX. The crash is exactly triggered by the following snippet: if sys.maxsi

[issue4929] smptlib.py can raise socket.error

STINNER Victor added the comment: Your patch looks fine but it would be much better with a test in Lib/test/test_smtp.py ;-) -- nosy: +haypo ___ Python tracker ___ _

[issue4807] wrong wsprintf usage

STINNER Victor added the comment: fprintf() is much better than wsprintf() + fputs() with a fixed size buffer (with no size/error check!). Same remark for PyString_FromFormat() instead of wsprintf()+PyString_FromString(). -- nosy: +haypo ___ Python

[issue4932] Little improvement on urlparse module, urlparse function.

STINNER Victor added the comment: It looks like most of your changes are already part of urlparse module of Python 2.6. Can you port your patch to Python 2.6 and retry your benchmark on Python 2.6? -- nosy: +haypo ___ Python tracker

[issue4804] Python on Windows disables all C runtime library assertions

Martin v. Löwis added the comment: > I submit to you a patch to the trunk which narrows down the problem. In > stead of throwing the switch for the whole process, we selectively > disable the hard error checking for those two cases that require it: -1. Setting the CRT report mode is not t

[issue4927] Inconsistent unicode repr for fileobject

Martin v. Löwis added the comment: > This leads to problems in the testsuite on vista. To which problem specifically? -- nosy: +loewis ___ Python tracker ___ ___

[issue4242] Classify language vs. impl-detail tests, step 1

Brett Cannon added the comment: At the language summit I actually plan on proposing separating out the Python the language and standard library from CPython. That would make this patch mostly unneeded as the CPython-specific tests and code would simply be kept separate from the language code tha

[issue4449] AssertionError in Doc/includes/mp_benchmarks.py

Jesse Noller added the comment: I agree with Martin - if no one else gets to this before me, I should be able to submit it within the next day. ___ Python tracker ___ ___

[issue4933] Patch to add preliminary support for Haiku

STINNER Victor added the comment: Python 2.5 branch is now frozen: only security fixes are accepted. You should work on 2.6 or better on Python trunk for faster integration of your patches ;-) Your patch looks good. -- nosy: +haypo ___ Python track

[issue4899] doctest should support fixtures

David W. Lambert added the comment: For unittests I recommend two things instead of need for doctest change. A decoupled strict test to prove that the iterator works, and this class to publish, class Tped_use_cases(...): def test_Marker_iteration(self): ''' Illustrativ

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

Jeffrey Yasskin 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 ar

  1   2   >