[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

Georg Brandl added the comment: Could you please stop putting these unrelated links into your posts? It is really annoying. Thanks. -- nosy: +georg.brandl ___ Python tracker __

[issue12797] io.FileIO and io.open should support openat

Ross Lagerwall added the comment: Attached is a patch which adds dirfd= as a keyword argument. -- keywords: +patch Added file: http://bugs.python.org/file23272/i12797.patch ___ Python tracker _

[issue12776] argparse: type conversion function should be called only once

Arnaud Fontaine added the comment: Any news about applying these patches? -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

Wong Wah Meng added the comment: Wow. I added it everywhere in the file. I love you!! (Ermm... I mean, literally) It can work now. :). I will move on to migrate my application with this new python. Hopefully I don't see other modules breaking. Thanks for the GREAT helps!!! :) $ python

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

Ezio Melotti added the comment: After the one at line 8620. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

Wong Wah Meng added the comment: Sorry, there a more than one entry of "#include " in configure file. So do I inject everywhere? Regards, Wah Meng Genesis Wafermap Support Ticket: To report a problem: http://dyno.freescale.net/Question/QuestionMain3.asp?location=zmy02&category=&tickettype=6

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

Wong Wah Meng added the comment: Thank goodness. Let me try. Regards, Wah Meng Genesis Wafermap Support Ticket: To report a problem: http://dyno.freescale.net/Question/QuestionMain3.asp?location=zmy02&category=&tickettype=6820 To request a service: http://dyno.freescale.net/Question/Questio

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

Ezio Melotti added the comment: You just have to add: #include just after: #include The + in the diff only means that the line was added and shouldn't be included in the file. -- ___ Python tracker __

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

Wong Wah Meng added the comment: Hello, I tried rebuild but it is still the same. :( Attached is the extract of the modified configure file, with line number at the side (from VI editor). Basically my changes are added as from line 8620 through 8624. I am not sure if this is meant to be, jus

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

Wong Wah Meng added the comment: Mercurial clone of python? Haha I am not sure what that is. My unix also won't recognize "hg", and will ignore "import --no-commit issue-13057.diff". I went ahead to edit configure file. Partially understanding the content of .diff file, I edited the configure

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

Ezio Melotti added the comment: If that's a Mercurial clone of Python you can try "hg import --no-commit issue-13057.diff". Otherwise you could just edit configure manually -- the attached patch is trivial. You could also install "patch". -- ___

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

Wong Wah Meng added the comment: I tried here is the outcome. It says it can't find a patch?? $ cat issue-13057.diff diff -r f612b783bc17 configure --- a/configure Thu Sep 29 07:52:46 2011 +0800 +++ b/configure Thu Sep 29 21:39:32 2011 +0200 @@ -8619,6 +8619,7 @@ cat confdefs.h - <<_AC

[issue12731] python lib re uses obsolete sense of \w in full violation of UTS#18 RL1.2a

Ezio Melotti added the comment: The failing re tests after PEP 393 are: FAIL lib re found non alphanumeric string 'cafe' FAIL lib re found non alphanumeric string 'Ⓚ' FAIL lib re found non alphanumeric string '' FAIL lib re found non alphanumeric string '' FAIL lib re found non alphanumeric

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

Ezio Melotti added the comment: "patch -p1 < issue-13057.diff" in the directory where configure is should do the trick. -- nosy: +ezio.melotti ___ Python tracker ___ __

[issue12737] str.title() is overzealous by upcasing combining marks inappropriately

Ezio Melotti added the comment: After PEP 393 the result is still the same (I attached a slightly improved version of the script): titlecase of 'deme un cafe' should be 'Deme Un Cafe' not 'DeMe Un Cafe' titlecase of 'istanbul' should be 'Istanbul' not 'IStanbul' titlecase of 'α στο

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

Wong Wah Meng added the comment: Hello Stefan, Hmm. how do I apply the patch? I download the issue-13057.diff file and then.? Regards, Wah Meng -- ___ Python tracker ___

[issue13071] IDLE refuses to open on windows 7

Ezio Melotti added the comment: Try to open cmd (win+r -> type 'cmd' -> press enter), cd in the Python directory and do "python.exe Lib\idlelib\idle.py". If that doesn't work it should give you a traceback. Once you get the traceback copy/paste it here, so we can figure out what's going on.

[issue13071] IDLE refuses to open on windows 7

New submission from jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal : I have tried all ways of opening IDLE and have uninstalled and reinstalled Python, but when I try to open it it crashes before anything happens -- components: IDLE messages: 144657 nosy: jfalskfjdsl;akfdjsa;l.laksfj;aslkfdj

[issue13072] Getting a buffer from a Unicode array uses invalid format

New submission from STINNER Victor : In Python 3.2, when you get a buffer from array.array('u'), "u" is used as buffer format. The format is supposed to be a format from the struct module, and "u" is an invalid struct format. "w" is used on wide mode. I just upgraded the array module to use th

[issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue13067] test

Changes by Ezio Melotti : -- resolution: -> invalid stage: -> committed/rejected ___ Python tracker ___ ___ Python-bugs-list mailing

[issue13068] test

Changes by Ezio Melotti : -- resolution: -> invalid stage: -> committed/rejected ___ Python tracker ___ ___ Python-bugs-list mailing

[issue13070] segmentation fault in pure-python multi-threaded server

New submission from Victor Semionov : Hello, I'm developing a multi-threaded TCP server and have been seeing segmentation faults on 3.2 on Linux and 3.2.2 on Windows. This happens when using only pure-Python libraries, so I believe the problem is in the interpreter. The issue is very easy to

[issue13069] test

Changes by Ezio Melotti : -- resolution: -> invalid stage: -> committed/rejected status: open -> closed ___ Python tracker ___ ___ P

[issue13069] test

New submission from Ezio Melotti : Testing issue creation -- hgrepos: 83 messages: 144655 nosy: ezio.melotti priority: normal severity: normal status: open title: test ___ Python tracker ___

[issue13068] test

Changes by Victor Semionov : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue13068] test

New submission from Victor Semionov : ignore me -- messages: 144654 nosy: vsemionov priority: normal severity: normal status: open title: test type: crash ___ Python tracker ___

[issue13061] Decimal module yields incorrect results when Python compiled with llvm

Ned Deily added the comment: There is some confusion here, I think. As best as I can tell, the original problem reported in the Stackoverflow question and to MacPorts involved using the clang compiler, not llvm-gcc and the Decimal problem reported here was only ever a problem when using clang

[issue13067] test

Changes by Victor Semionov : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue13067] test

New submission from Victor Semionov : ignore me -- components: IO, Interpreter Core files: backtrace messages: 144651 nosy: vsemionov priority: normal severity: normal status: open title: test type: crash versions: Python 3.2 Added file: http://bugs.python.org/file23269/backtrace __

[issue13066] test

Changes by Ezio Melotti : -- resolution: -> invalid stage: -> committed/rejected ___ Python tracker ___ ___ Python-bugs-list mailing

[issue13065] test

Changes by Ezio Melotti : -- resolution: -> invalid stage: -> committed/rejected ___ Python tracker ___ ___ Python-bugs-list mailing

[issue13066] test

Changes by Victor Semionov : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue13066] test

New submission from Victor Semionov : ignore me -- components: IO, Interpreter Core messages: 144648 nosy: vsemionov priority: normal severity: normal status: open title: test type: crash versions: Python 3.2 ___ Python tracker

[issue13065] test

Changes by Victor Semionov : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue13065] test

New submission from Victor Semionov : ignore me -- messages: 144647 nosy: vsemionov priority: normal severity: normal status: open title: test ___ Python tracker ___

[issue11489] json.dumps not parsable by json.loads (on Linux only)

Ezio Melotti added the comment: RFC 4627 doesn't say much about lone surrogates: A string is a sequence of zero or more Unicode characters [UNICODE]. [...] All Unicode characters may be placed within the quotation marks except for the characters that must be escaped: quotation ma

[issue2771] Test issue

Changes by Victor Semionov : -- hgrepos: -78 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue2771] Test issue

Victor Semionov added the comment: adsfaf -- hgrepos: +78 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue2771] Test issue

Victor Semionov added the comment: testing -- Added file: http://bugs.python.org/file23266/test.txt ___ Python tracker ___ ___ Python-

[issue2771] Test issue

Victor Semionov added the comment: Testing. -- nosy: +vsemionov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue13062] Introspection generator and function closure state

Nick Coghlan added the comment: Huh, I didn't actually realise getclosure() could be written as a one liner until seeing Meador's version above: {var : cell.cell_contents for var, cell in zip(func.__code__.co_freevars, func.__closure__)} -- ___

[issue13062] Introspection generator and function closure state

Nick Coghlan added the comment: Yep, that looks right to me. The eval loop then references those cells from the frame object during execution. -- ___ Python tracker ___ ___

[issue13064] Port codecs and error handlers to the new Unicode API

Changes by Ezio Melotti : -- nosy: +ezio.melotti stage: -> needs patch type: -> feature request ___ Python tracker ___ ___ Python-bu

[issue13064] Port codecs and error handlers to the new Unicode API

New submission from STINNER Victor : We really need a new API for error handlers, using Python objects instead of Py_UNICODE* strings, and using code point indexes instead of UTF-16 unit indexes (index in the Py_UNICODE* object). It's also inefficient to encode to Py_UNICODE at the first encod

[issue13061] Decimal module yields incorrect results when Python compiled with llvm

Changes by Mark Dickinson : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue13062] Introspection generator and function closure state

Eric Snow added the comment: See: http://hg.python.org/cpython/file/default/Include/funcobject.h#l34 http://hg.python.org/cpython/file/default/Objects/funcobject.c#l454 454 /* func_new() maintains the following invariants for closures. The 455closure must correspond to the free vari

[issue13061] Decimal module yields incorrect results when Python compiled with llvm

Stefan Krah added the comment: It's more a straight duplicate of #12973, but the underlying cause (signed integer overflow) is the same. For people who are finding this via a search engine: A lot of bugs have been fixed in #12973, but even if the test suite passes without -fwrapv it is *still* r

[issue13062] Introspection generator and function closure state

Meador Inge added the comment: I'll take a shot and writing a patch for this one. Nick, are the elements in 'co_freevars' and '__closures__' always expected to match up? In other words, is the 'closure' function below always expected to work (simplified; no error checking): >>> def make_add

[issue12242] distutils2 environment marker for current compiler

Eli Collins added the comment: > What is result is i use GNU compiler by example with name > arm-linux-androideabi-gcc ? If the executable is named "arm-linux-androideabi-gcc", the code would currently call "arm-linux-androideabi-gcc --version". If that resulted in (for example) "arm-linux-

[issue12819] PEP 393 - Flexible Unicode String Representation

Changes by Ezio Melotti : -- stage: patch review -> committed/rejected ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue12819] PEP 393 - Flexible Unicode String Representation

STINNER Victor added the comment: PEP 393 has been accepted and merged into Python 3.3. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ __

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Ezio Melotti added the comment: Py_UNICODE_NEXT has been removed from 3.3 but it's still available and used in 2.7/3.2 (even if it's private). In order to fix #10521 on 2.7/3.2 the _Py_UNICODE_PUT_NEXT macro attached to this patch is required. -- versions: +Python 3.3 -Python 3.2 __

[issue10521] str methods don't accept non-BMP fillchar on a narrow Unicode build

Ezio Melotti added the comment: It can still be fixed on 2.7/3.2 though. -- versions: +Python 2.7 ___ Python tracker ___ ___ Python-b

[issue10521] str methods don't accept non-BMP fillchar on a narrow Unicode build

STINNER Victor added the comment: This issue has been fixed in Python 3.3 thanks to the PEP 393. -- nosy: +haypo ___ Python tracker ___ _

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor added the comment: The PEP 393 has been accepted and merge into Python 3.3. Python 3.3 doesn't need the Py_UNICODE_NEXT macro anymore. But my macros (unicode_macros.patch) are still useful. -- versions: +Python 3.2 -Python 3.3 ___ Py

[issue12242] distutils2 environment marker for current compiler

Eli Collins added the comment: Attached is a fourth revision (ca53ff77ce6f.diff). This covers the typos identified in the last review, but I'm submitting a new patch because I ran a quick proofreading regexp, and identified a few more formatting mistakes. --

[issue12242] distutils2 environment marker for current compiler

Changes by Eli Collins : Added file: http://bugs.python.org/file23263/ca53ff77ce6f.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue12242] distutils2 environment marker for current compiler

Roumen Petrov added the comment: What is result is i use GNU compiler by example with name arm-linux-androideabi-gcc ? -- nosy: +rpetrov ___ Python tracker ___ ___

[issue12632] Python 3 doesn't support cp65001 as the OEM code page

Changes by STINNER Victor : -- title: Windows GPF with Code Page 65001 -> Python 3 doesn't support cp65001 as the OEM code page ___ Python tracker ___ __

[issue11574] TextIOWrapper: Unicode Fallback Encoding on Python 3.3

Changes by STINNER Victor : -- title: Unicode Fallback Encoding on Python 3.3 -> TextIOWrapper: Unicode Fallback Encoding on Python 3.3 ___ Python tracker ___ __

[issue7330] PyUnicode_FromFormat: implement width and precision for %s, %S, %R, %V, %U, %A

STINNER Victor added the comment: Hum, the issue is still open, I will try to review it. -- ___ Python tracker ___ ___ Python-bugs-lis

[issue1943] improved allocation of PyUnicode objects

STINNER Victor added the comment: The PEP 393 is based on the idea proposed in this issue (use only one memory block, not two), but also enhanced it to reduce more the memory using other technics: - use a different character type depending on the maximum character, - use a shorter structure

[issue13061] Decimal module yields incorrect results when Python compiled with llvm

Changes by Ned Deily : -- nosy: +ned.deily ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue2799] Remove _PyUnicode_AsString(), rework _PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()

STINNER Victor added the comment: The PEP 393 changed the API: #define _PyUnicode_AsString PyUnicode_AsUTF8 #define _PyUnicode_AsStringAndSize PyUnicode_AsUTF8AndSize -- ___ Python tracker

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

Stefan Krah added the comment: To me this looks like stdio.h should be included as well. Could you try the patch? -- keywords: +patch Added file: http://bugs.python.org/file23262/issue-13057.diff ___ Python tracker

[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds

Daniel Stutzbach added the comment: Gladly. :-) -- resolution: -> out of date stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___ ___

[issue13061] Decimal module yields incorrect results when Python compiled with llvm

Joshua Bleecher Snyder added the comment: >> Possibly related to http://bugs.python.org/issue11149? > Maybe I missed it in the links you gave, but that is easily > settled by compiling with and without -fwrapv. Apologies -- I didn't do enough homework on this one. Yes, I can confirm that comp

[issue13054] sys.maxunicode value after PEP-393

Antoine Pitrou added the comment: I think there's no point in deprecating a function (or data) with a perfectly valid definition. As for test_bigmem, better keep character_size hardwired to 1 (if all tests really use only ASCII chars, which I'm not sure they do). -- _

[issue4489] shutil.rmtree is vulnerable to a symlink attack

Ross Lagerwall added the comment: Updated patch based on Eric's comments: Store _supports_safe_rmdir at the module level. Move imports up to module level Skip test on non-threading build -- Added file: http://bugs.python.org/file23261/i4489_v4.patch _

[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds

STINNER Victor added the comment: The PEP 393 has been accepted. There is no more narrow or wide build, Py_UNICODE is now always wchar_t. We have also a stable ABI which doesn't depend on the internal stucture of Unicode strings. In Python 3.2, the name of dynamic libraries is also different

[issue7652] Merge C version of decimal into py3k.

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue13062] Introspection generator and function closure state

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue13060] allow other rounding modes in round()

Arne Babenhauserheide added the comment: cdecimal sounds great! when is it scheduled for inclusion? -- ___ Python tracker ___ ___ Pyt

[issue3130] In some UCS4 builds, sizeof(Py_UNICODE) could end up being more than 4.

STINNER Victor added the comment: The PEP 393 has been accepted: strings are now stored as PyUCS1*, PyUCS2* or PyUCS4*. The Py_UNICODE type still exist but is deprecated, and only used in the legacy API. Py_UNICODE is now always the wchar_t type, it cannot be unsigned int anymore. I hope that

[issue13061] Decimal module yields incorrect results when Python compiled with llvm

Stefan Krah added the comment: > Possibly related to http://bugs.python.org/issue11149? Maybe I missed it in the links you gave, but that is easily settled by compiling with and without -fwrapv. -- nosy: +skrah ___ Python tracker

[issue13059] Sporadic test_multiprocessing failure: IOError("bad message length") in recv_bytes()

STINNER Victor added the comment: See also issue #13063. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue13063] test_concurrent_futures failures on Windows: IOError('[Errno 232] The pipe is being closed') on _send_bytes()

New submission from STINNER Victor : Re-running test 'test_concurrent_futures' in verbose mode test_killed_child (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 5.79s ok test_map (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 3.63s ok test_map_exception (test.test_concurre

[issue13063] test_concurrent_futures failures on Windows: IOError('[Errno 232] The pipe is being closed') on _send_bytes()

STINNER Victor added the comment: See also issue #13059. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue13062] Introspection generator and function closure state

Changes by Yury Selivanov : -- nosy: +Yury.Selivanov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue13062] Introspection generator and function closure state

Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue13062] Introspection generator and function closure state

Changes by Meador Inge : -- components: +Library (Lib) stage: -> needs patch versions: +Python 3.3 ___ Python tracker ___ ___ Python-

[issue13054] sys.maxunicode value after PEP-393

STINNER Victor added the comment: As said on IRC, unicodesize and character_size should be 1 before the test is something like 'x'*1. Or you can just remove this constant, it's not very useful to have a constant equal to 1 :-) -- ___ Python tracker

[issue12746] normalization is affected by unicode width

STINNER Victor added the comment: Issue fixed in Python 3.3 by Martin, changesets 40cf7204ca2b and 50f008019213. -- nosy: +loewis resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue13060] allow other rounding modes in round()

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue13058] Fix file descriptor leak on error

Charles-François Natali added the comment: Patch applied, thanks! -- nosy: +neologix resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4 ___ Python tracker

[issue13058] Fix file descriptor leak on error

Roundup Robot added the comment: New changeset dec00ae64ca8 by Charles-François Natali in branch '2.7': Issue #13058: ossaudiodev: fix a file descriptor leak on error. Patch by Thomas http://hg.python.org/cpython/rev/dec00ae64ca8 New changeset 160b52c9e8b3 by Charles-François Natali in branch '

[issue11457] os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution

Stefan Krah added the comment: > BTW, what is the status of cdecimal? I just wrote the same in another issue, but not everyone is subscribed to that: I think cdecimal is finished and production ready. The version in http://hg.python.org/features/cdecimal#py3k-cdecimal is the same as what wil

[issue13062] Introspection generator and function closure state

New submission from Nick Coghlan : Based on the python-ideas thread about closures, I realised there are two features the inspect module could offer to greatly simplify some aspects of testing closure and generator behaviour: inspect.getclosure(func) Returns a dictionary mapping closure

[issue13061] Decimal module yields incorrect results when Python compiled with llvm

New submission from Joshua Bleecher Snyder : When Python is compiled on OS X with llvm, the decimal module behaves erratically (simple calculations are wrong, most doctests fail). This was originally reported here: http://stackoverflow.com/questions/7590137/dividing-decimals-yields-invalid-res

[issue11457] os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution

Changes by STINNER Victor : -- title: Expose nanosecond precision from system calls -> os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution ___ Python tracker _

[issue13060] allow other rounding modes in round()

Stefan Krah added the comment: > If the C accelerator for decimal gets decimal performance close to > floats (which I doubt, because it has to do much more), it could be > very useful for me. What is its estimated time to completion? It is finished and awaiting review (See #7652). The version

[issue13060] allow other rounding modes in round()

Mark Dickinson added the comment: > maybe there should be a warning in the 2.7 documentation Well, such a warning really belongs in the Python 3 documentation rather than the Python 2 documentation. (Or at least, AFAIK that's the convention that's been followed to date: the Python 2 docs do

[issue13060] allow other rounding modes in round()

Arne Babenhauserheide added the comment: I did not know about rounding to even, so maybe there should be a warning in the 2.7 documentation, that the behavior changed in python 3 (I just checked that: python2.7 is in line with the documentation). The first time I stumbled over these issues w

[issue13060] make round() floating-point errors less hurtful

Mark Dickinson added the comment: Classifying this as a feature request: the behaviour of round isn't going to change here, but there might be community support for adding a mechanism for round to allow other rounding modes. It might be worth taking this to the python-ideas mailing list to

[issue13060] make round() floating-point errors less hurtful

Changes by Mark Dickinson : -- type: -> feature request versions: +Python 3.3 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list

[issue13060] make round() floating-point errors less hurtful

Mark Dickinson added the comment: > This is mathematically wrong ... No, it's not 'mathematically wrong'. There are many different rounding conventions in use, and no single universally agreed convention for rounding halfway cases. Python chooses to use unbiased rounding[1] here, which matc

[issue13060] make round() floating-point errors less hurtful

R. David Murray added the comment: It seems to me that saying "floating point" and "mathematically correct" in the same breath is...optimistic :) But that's why I added Mark to nosy, he knows far more about this stuff than I do. As far as I know the accelerator is feature complete at this po

[issue13060] make round() floating-point errors less hurtful

Arne Babenhauserheide added the comment: If the C accelerator for decimal gets decimal performance close to floats (which I doubt, because it has to do much more), it could be very useful for me. What is its estimated time to completion? Even when it is finished, it does not change the proble

[issue13060] make round() floating-point errors less hurtful

Arne Babenhauserheide added the comment: Better comparision of decimal and float: >>> timeit("a+a", setup="from decimal import Decimal, getcontext; >>> getcontext().prec=17; a = Decimal(1.0)") 21.125790119171143 >>> timeit("a+a", setup="a = float(1.0)") 0.05324697494506836 -- __

  1   2   >