[issue16296] Patch to fix building on Win32/64 under VS 2010
Paul Moore added the comment: Is there any chance this can be included in Python 3.4? It would apparently allow numpy to be built with stock tools on Windows Python. -- nosy: +pmoore ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17162] Py_LIMITED_API needs a PyType_GenericDealloc
Roundup Robot added the comment: New changeset 655d7a55c165 by Martin v. Löwis in branch 'default': Issue #17162: Add PyType_GetSlot. http://hg.python.org/cpython/rev/655d7a55c165 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17162] Py_LIMITED_API needs a PyType_GenericDealloc
Martin v. Löwis added the comment: Thanks for the reviews; this is now committed. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17162] Py_LIMITED_API needs a PyType_GenericDealloc
Roundup Robot added the comment: New changeset eaae4008327d by Victor Stinner in branch 'default': Issue #17162: Fix compilation, replace non-breaking space with an ASCII space http://hg.python.org/cpython/rev/eaae4008327d -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17162 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files
Vajrasky Kok added the comment: Here is the updated patch after Larry's commit to clinic. Everything is included except codecsmodule. -- Added file: http://bugs.python.org/file33895/issue20173_conglomerate.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20173 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20505] Remove resolution from selectors and granularity from asyncio
STINNER Victor added the comment: Here is a script to measure the accuracy of asyncio: min/max difference between the scheduled time and the real elapsed time. It's not directly related to the attached patch, but it can help if you want to implement a different option like Results on my Fedora 20 (Linux kernel 3.12) with Python compiled in debug mode. Results with the original code: --- [ asyncio accuracy ] call_later(0.0001 us): difference in [59.4839 us; 101.6307 us], [+59483938.5%, +101630708.8%] call_later(0.0005 us): difference in [59.1285 us; 129.9486 us], [+11825694.4%, +25989713.7%] call_later(0.0010 us): difference in [58.9950 us; 102.4589 us], [+5899502.5%, +10245891.9%] call_later(0.0015 us): difference in [59.0737 us; 100.6987 us], [+3938245.9%, +6713245.6%] call_later(0.0020 us): difference in [58.6790 us; 112.8620 us], [+2933950.3%, +5643097.8%] call_later(0.0030 us): difference in [58.9260 us; 118.2042 us], [+1964199.0%, +3940139.5%] call_later(0.0040 us): difference in [59.3839 us; 117.6248 us], [+1484597.0%, +2940620.9%] call_later(0.0050 us): difference in [58.9361 us; 115.3991 us], [+1178721.5%, +2307982.8%] call_later(0.1 us): difference in [61.1 us; 133.5 us], [+61131.0%, +133512.9%] call_later(0.5 us): difference in [59.0 us; 124.8 us], [+11793.8%, +24953.6%] call_later(1.0 us): difference in [57.7 us; 113.7 us], [+5770.7%, +11372.1%] call_later(1.5 us): difference in [57.2 us; 113.5 us], [+3816.0%, +7563.7%] call_later(2.0 us): difference in [56.4 us; 130.1 us], [+2822.0%, +6506.8%] call_later(3.0 us): difference in [55.1 us; 99.7 us], [+1836.5%, +3324.5%] call_later(4.0 us): difference in [53.8 us; 98.5 us], [+1345.3%, +2462.4%] call_later(5.0 us): difference in [54.6 us; 97.0 us], [+1091.2%, +1939.9%] call_later(10.0 us): difference in [76.8 us; 114.3 us], [+767.6%, +1142.5%] call_later(50.0 us): difference in [44.5 us; 1154.6 us], [+88.9%, +2309.3%] call_later(0.1 ms): difference in [1.1 ms; 1.2 ms], [+1061.3%, +1153.8%] call_later(100.0 us): difference in [1066.1 us; 1134.3 us], [+1066.1%, +1134.3%] call_later(150.0 us): difference in [1005.0 us; 1104.6 us], [+670.0%, +736.4%] call_later(200.0 us): difference in [940.3 us; 1024.9 us], [+470.2%, +512.4%] call_later(300.0 us): difference in [854.2 us; 942.4 us], [+284.7%, +314.1%] call_later(400.0 us): difference in [756.3 us; 841.4 us], [+189.1%, +210.3%] call_later(0.5 ms): difference in [0.6 ms; 0.8 ms], [+129.2%, +151.6%] call_later(500.0 us): difference in [648.7 us; 734.8 us], [+129.7%, +147.0%] call_later(1.0 ms): difference in [0.1 ms; 0.3 ms], [+14.7%, +26.0%] call_later(1.5 ms): difference in [0.7 ms; 0.8 ms], [+43.5%, +51.3%] call_later(2.0 ms): difference in [0.2 ms; 0.2 ms], [+7.7%, +10.6%] call_later(3.0 ms): difference in [0.2 ms; 0.2 ms], [+6.2%, +8.1%] call_later(4.0 ms): difference in [0.2 ms; 0.2 ms], [+4.1%, +6.0%] call_later(5.0 ms): difference in [0.2 ms; 0.3 ms], [+3.0%, +5.6%] call_later(10.0 ms): difference in [0.1 ms; 0.3 ms], [+1.3%, +2.6%] call_later(10.0 ms): difference in [0.2 ms; 0.3 ms], [+2.0%, +2.8%] call_later(15.0 ms): difference in [0.2 ms; 0.3 ms], [+1.2%, +1.7%] call_later(20.0 ms): difference in [0.2 ms; 1.9 ms], [+1.1%, +9.3%] call_later(30.0 ms): difference in [0.2 ms; 0.3 ms], [+0.7%, +1.0%] call_later(40.0 ms): difference in [0.2 ms; 0.3 ms], [+0.5%, +0.8%] call_later(50.0 ms): difference in [0.2 ms; 0.3 ms], [+0.4%, +0.5%] call_later(100.0 ms): difference in [0.3 ms; 0.4 ms], [+0.3%, +0.4%] call_later(100.000 ms): difference in [0.254 ms; 0.384 ms], [+0.3%, +0.4%] call_later(150.0 ms): difference in [0.3 ms; 0.4 ms], [+0.2%, +0.3%] call_later(200.0 ms): difference in [0.2 ms; 0.4 ms], [+0.1%, +0.2%] call_later(300.0 ms): difference in [0.5 ms; 0.5 ms], [+0.2%, +0.2%] call_later(400.0 ms): difference in [0.5 ms; 0.7 ms], [+0.1%, +0.2%] call_later(500.0 ms): difference in [0.7 ms; 0.8 ms], [+0.1%, +0.2%] call_later(500.000 ms): difference in [0.297 ms; 0.786 ms], [+0.1%, +0.2%] call_later(1000.000 ms): difference in [0.439 ms; 1.285 ms], [+0.0%, +0.1%] call_later(1500.000 ms): difference in [0.916 ms; 1.759 ms], [+0.1%, +0.1%] call_later(2000.000 ms): difference in [0.678 ms; 2.297 ms], [+0.0%, +0.1%] call_later(3000.000 ms): difference in [0.444 ms; 3.275 ms], [+0.0%, +0.1%] call_later(4000.000 ms): difference in [0.516 ms; 4.255 ms], [+0.0%, +0.1%] call_later(5000.000 ms): difference in [1.051 ms; 5.242 ms], [+0.0%, +0.1%] Global accuracy in [44.5 us; 5.2 ms] Loop granularity: 1.0 ms Selector resolution: 1.0 ms Event loop: _UnixSelectorEventLoop Selector: EpollSelector --- IMO a maximum difference of 5.2 ms with a granularity of 1 ms is very good. For a call scheduled in 1 ms, the difference is in range [0.1 ms; 0.3 ms] which is also very good. Results with remove_granularity.patch: --- [ asyncio accuracy ] call_later(0.0001 us): difference in [65.1941 us; 95.9378 us], [+65194110.0%, +95937766.7%] call_later(0.0005 us): difference in [64.9974 us; 109.2616 us],
[issue20505] Remove resolution from selectors and granularity from asyncio
Changes by STINNER Victor victor.stin...@gmail.com: Added file: http://bugs.python.org/file33897/add_granularity.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20491] textwrap: Non-breaking space not honored
Serhiy Storchaka added the comment: It looks to me that code can be a little more clear if use C-style formatting. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20491 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14911] generator.throw() documentation inaccurate
Kristján Valur Jónsson added the comment: Note that the docstring does not match the doc: PyDoc_STRVAR(throw_doc, throw(typ[,val[,tb]]) - raise exception in generator,\n\ return next yielded value or raise StopIteration.); Should I change the docstring too? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14911 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16296] Patch to fix building on Win32/64 under VS 2010
Tim Golden added the comment: Larry Hastings would have to rule on whether it could get into 3.4 at this stage. Paul: are you in a position to apply / test the patch? I've done no more than glance at it but it looks, from the comments, as though it doesn't apply cleanly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6299] pyexpat build failure on Solaris 10 for 2.6.1/2.6.2
koobs added the comment: The issue applies and is reproducible for all versions 2.6 through 3.5. This is the changeset we applied to all FreeBSD Ports to fix the issue: https://svnweb.freebsd.org/ports?view=revisionrevision=326729 One specific example (Python 3.3): 1) Use CPPFLAGS over CFLAGS (See before *and* after comments): https://svnweb.freebsd.org/ports/head/lang/python33/Makefile?r1=326729r2=326728pathrev=326729 2) Revert the absolutely crazy complexity in Makefile.pre.in by stripping out CONFIGURE_*, allowing once again ./configure to substitute the right variables based on what has been passed to it: https://svnweb.freebsd.org/ports/head/lang/python33/files/patch-Makefile.pre.in?r1=326729r2=326728pathrev=326729 This results in: Makefile.pre.in: CPPFLAGS= @CPPFLAGS@ -- YAY! PY_CPPFLAGS=$(BASECPPFLAGS) -I. -IInclude -I$(srcdir)/Include $(CPPFLAGS) -- YAY Makefile: CPPFLAGS= -I/usr/local/include - YAY! PY_CPPFLAGS=$(BASECPPFLAGS) -I. -IInclude -I$(srcdir)/Include $(CPPFLAGS) -- YAY! The root cause *requiring* the use of CPPFLAGS, is PY_CFLAGS before PY_CPPFLAGS here: PY_CORE_CFLAGS= $(PY_CFLAGS) $(PY_CPPFLAGS) $(CFLAGSFORSHARED) -DPy_BUILD_CORE As per https://www.gnu.org/prep/standards/html_node/Command-Variables.html Put CFLAGS last in the compilation command, after other variables containing compiler options, so the user can use CFLAGS to override the others. We must use CPPFLAGS, because CFLAGS has been broken in one way or another for a long time. The target state is *both* must just work. This can only happen if the standard user-serviceable autoconf and Makefile variables are left alone, not extended or overridden, and behave in exactly the same way whether provided in the environment for *either* ./configure, make, or *both*. For the most recent chapter in the C[PP|LD]FLAGS/Makefile book, see: 92a9dc668c95 from #9189 which was sound in intent, but in execution left us deeper down the rabbit-hole. Moving forward and as a first step, what does everyone think of switching the order of $(PY_CFLAGS) $(PY_CPPFLAGS) in PY_CORE_CFLAGS= ? I hope (but I'm not holding my breath) that nothing relies on the current ordering. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6299 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16296] Patch to fix building on Win32/64 under VS 2010
Paul Moore added the comment: Unfortunately not really - it's the numpy guys that need this, so hopefully the original poster can comment. I'll see if I can hand-patch the relevant files and do a pip install numpy to see if it fixes that specific scenario. I'll report back. I've added Larry Hastings to the nosy list for his comments. -- nosy: +larry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16296] Patch to fix building on Win32/64 under VS 2010
Paul Moore added the comment: Sigh. Looks like it doesn't fix the issue of building numpy - plus it doesn't apply cleanly. My apologies for the noise, I'll report the issues with the patch back on the numpy issue where I was told about this patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16296] Patch to fix building on Win32/64 under VS 2010
Larry Hastings added the comment: I'm not sure I need to be on this issue. As a rule, Windows build concerns for 3.4 are delegated to Martin von Lowis. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20218] Add `pathlib.Path.write` and `pathlib.Path.read`
Ram Rachum added the comment: Hi everyone, I'm waiting for someone to review my patch. I believe it includes everything that's needed to merge. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20218 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16296] Patch to fix building on Win32/64 under VS 2010
Tim Golden added the comment: Thanks, Larry. Martin's already nosy this issue, but really we need to see if we have a viable patch before making decisions about 3.4. I'll take you off the nosy list. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16296] Patch to fix building on Win32/64 under VS 2010
Changes by Tim Golden m...@timgolden.me.uk: -- nosy: -larry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17925] asynchat.async_chat.initiate_send : del deque[0] is not safe
Pierrick Koch added the comment: Fix patch from Xavier's comment, sorry for the delay. Lib/test/test_asynchat.py passes (Ran 27 tests in 1.431s) -- Added file: http://bugs.python.org/file33898/cpython.asyncore_4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17925 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20404] Delayed exception using non-text encodings with TextIOWrapper
Nick Coghlan added the comment: v3: - prefix for internal helper APIs is now _PyCodecInfo_ to better distinguish them from the ones that take an encoding name - error check is now just for is not a text encoding - tweaked the name and comment in the error test to be clear that it is codecs that are not marked as text encodings that are rejected, not just binary transforms - fixed indentation of multi-line expression in _pyio.py -- Added file: http://bugs.python.org/file33899/issue20404_check_valid_textio_codec_v3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20404 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20502] Context.create_decimal_from_float() inconsistent precision for zeros after decimal mark
Mark Dickinson added the comment: The output is correct, though the tiny precision makes it look strange. The decimal module is following the usual rules for 'ideal' exponents: - For *exactly representable* results, the ideal exponent is 0, and the output will be chosen to have exponent as close to that as possible (while not altering the value of the result). - Where the result isn't exactly representable, full precision is used. Those two rules together explain all of the output you showed: 100.0, 10.0 and 1.0 are exactly representable, so we aim for an exponent of 0. But 100.0 can't be expressed in only 2 digits with an exponent of 0, so it ends up with an exponent of 1, hence the `1.0E+2` output. 460.0 and 46.0 are similarly exactly representable. 4.6 and 0.46 are not exactly representable, so the output is given to full precision. -- resolution: - invalid status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20502 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20404] Delayed exception using non-text encodings with TextIOWrapper
Serhiy Storchaka added the comment: LGTM. -- stage: test needed - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20404 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20507] TypeError from str.join has no message
New submission from Gareth Rees: If you pass an object of the wrong type to str.join, Python raises a TypeError with no error message: Python 3.4.0b3 (default, Jan 27 2014, 02:26:41) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin Type help, copyright, credits or license for more information. ''.join(1) Traceback (most recent call last): File stdin, line 1, in module TypeError It is unnecessarily hard to understand from this error what the problem actually was. Which object had the wrong type? What type should it have been? Normally a TypeError is associated with a message explaining which type was wrong, and what it should have been. For example: b''.join(1) Traceback (most recent call last): File stdin, line 1, in module TypeError: can only join an iterable It would be nice if the TypeError from ''.join(1) included a message like this. The reason for the lack of message is that PyUnicode_Join starts out by calling PySequence_Fast(seq, ) which suppresses the error message from PyObject_GetIter. This commit by Tim Peters is responsible: http://hg.python.org/cpython/rev/8579859f198c. The commit message doesn't mention the suppression of the message so I can assume that it was an oversight. I suggest replacing the line: fseq = PySequence_Fast(seq, ); in PyUnicode_Join in unicodeobject.c with: fseq = PySequence_Fast(seq, can only join an iterable); for consistency with bytes_join in stringlib/join.h. Patch attached. -- components: Interpreter Core files: join.patch keywords: patch messages: 210200 nosy: Gareth.Rees priority: normal severity: normal status: open title: TypeError from str.join has no message type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file33900/join.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20507 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6299] pyexpat build failure on Solaris 10 for 2.6.1/2.6.2
koobs added the comment: Setting versions to correctly reflect those affected. -- versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6299 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20481] Clarify type coercion rules in statistics module
Nick Coghlan added the comment: I think it's also acceptable at this point for the module docs to just say that handling of mixed type input is undefined and implementation dependent, and recommend doing map(int, input_data), map(float, input_data), map(Decimal, input_data) or map(Fraction, input_data) to ensure getting a consistent answer for mixed type input. I believe it would also be acceptable for the module to just fail immediately as soon as it detects an input type that differs from the type of the first value rather than attempting to guess the most appropriate behaviour. This close to 3.4rc1 (Sunday 9th February), I don't think we want to be committing to *any* particular implementation of type coercion. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20481 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20489] help() fails for zlib Compress and Decompress objects
Nick Coghlan added the comment: For 3.4, I'd prefer to just not convert these functions. The right fix is to figure out how to get __name__ set appropriately, and that's something the C extension module improvements in 3.5 should be able to help with. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20489 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20489] help() fails for zlib Compress and Decompress objects
Nick Coghlan added the comment: For example, see the builtins patch on issue 20184 where I initially converted sorted() to AC, but then found that making it *work* as an AC function was actually quite difficult due to the PyList implementation expecting to be given a arg tuple and kwds dict. Something like that seems appropriate here as well - break the magic formatting of the clinic input, add a reference to this bug and then tweak the signature line manually to not be a valid AC signature line. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20489 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15216] Support setting the encoding on a text stream after creation
Nick Coghlan added the comment: If operating systems always exposed accurate metadata and configuration settings, I'd agree with you. They don't though, so sometimes developers need to be able to override whatever the interpreter figured out automatically. In addition, needing to cope with badly designed APIs is an unfortunate fact of life - that's why monkeypatching is only *discouraged*, rather than disallowed :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15216 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20502] Context.create_decimal_from_float() inconsistent precision for zeros after decimal mark
Mauricio de Alencar added the comment: According to the docs (http://docs.python.org/3/library/decimal.html): The decimal module incorporates a notion of significant places so that 1.30 + 1.20 is 2.50. The trailing zero is kept to indicate significance. This is the customary presentation for monetary applications. For multiplication, the “schoolbook” approach uses all the figures in the multiplicands. For instance, 1.3 * 1.2 gives 1.56 while 1.30 * 1.20 gives 1.5600. Therefore, if I request 2 digits of precision, I expect 2 digits in the output. In addition, the docs assert that Decimal numbers can be represented exactly, which leaves me lost about you argument on whether some number is *exactly representable* or not. -- resolution: invalid - status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20502 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20507] TypeError from str.join has no message
Srinivas Reddy T added the comment: The exact behavior is present in 2.7 version too. So tagging 2.7 to 3.4 -- nosy: +thatiparthy versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20507 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20485] Enable 'import Non-ASCII.pyd'
Nick Coghlan added the comment: import-...@python.org would be the appropriate list for this one. However, we can't do anything about it until Python 3.5 next year at the earliest, and I'm already planning to write a follow-up to http://www.python.org/dev/peps/pep-0451/ that adapts the extension module import mechanism to support those APIs (addressing a number of longstanding feature requests from the Cython developers). That said, this is an independent proposal, so if you were willing to write it up as a separate PEP, that would be probably be a good idea. Our two choices to consider would be: 1. Using a custom 7-bit ASCII compatible encoding to support this on arbitrary C compilers (at the cost of making the identifiers unintuitive). (i.e. the approach in your patch) 2. Using the Universal Character Name support originally specified in C99, but retained in C11 (these are the \U and \u escapes familiar from Python text literals). Note that *CPython* still won't need to be compiled with a compiler that supports UCN for this to work - we'll just need the dynamic linking API to support us looking for a symbol containing such a name. Option 2 is what I think we *should* do, but there will be some research involved in figuring out how good the current support for UCN C identifiers is in at least gcc, clang and Visual Studio 2013, as well as what the dynamic linker APIs support in terms of passing identifiers containing Unicode escapes to be looked up in the exported symbols. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20485 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20489] help() fails for zlib Compress and Decompress objects
Serhiy Storchaka added the comment: Expressly writing the name of the module in the expression solves this issue. -- stage: - patch review Added file: http://bugs.python.org/file33901/zlib_parameters_defaults.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20489 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20507] TypeError from str.join has no message
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +pitrou stage: - patch review versions: -Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20507 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20502] Context.create_decimal_from_float() inconsistent precision for zeros after decimal mark
Mark Dickinson added the comment: Therefore, if I request 2 digits of precision, I expect 2 digits in the output. The `prec` attribute in the context refers to the total number of *significant digits* that are storable, and not to the number of digits after the decimal point. `Decimal` is at heart a floating-point type, not a fixed-point one (though the handling of significant zeros that you note means that it's useful in fixed-point contexts too). For typical uses you'll want `prec` to be much bigger than 2. So the number of trailing zeros is typically determined not by `prec` but by the exponents of the operands to any given operation. In the example you cite, the output is `2.50` because the inputs both had two digits after the point. the docs assert that Decimal numbers can be represented exactly Sure, but for example the 0.1 in your code is not a Decimal: it's a Python float, represented under the hood in binary. Its exact value is 0.155511151231257827021181583404541015625, and that can't be stored exactly in a Decimal object with only two digits of precision. So the behaviour you identify isn't a bug: the module is following a deliberate design choice here. -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20502 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6299] pyexpat build failure on Solaris 10 for 2.6.1/2.6.2
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6299 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5680] Command-line arguments when running in IDLE
Changes by Tal Einat talei...@gmail.com: -- nosy: -taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5680 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1528593] Printing: No print dialog or page setup
Changes by Tal Einat talei...@gmail.com: -- nosy: -taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1528593 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20485] Enable 'import Non-ASCII.pyd'
STINNER Victor added the comment: we *should* do, but there will be some research involved in figuring out how good the current support for UCN C identifiers is in at least gcc, clang and Visual Studio 2013 Python 3.4 uses Visual Studio 2010. I'm not sure that you can build an extension with VS 2013 if Python was build with VS 2010. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20485 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1253] IDLE - Percolator overhaul
Changes by Tal Einat talei...@gmail.com: -- nosy: -taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1253 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4832] IDLE does not supply a default ext of .py on Windows or OS X for new file saves
Changes by Tal Einat talei...@gmail.com: -- nosy: -taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4832 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2704] IDLE: Patch to make PyShell behave more like a Terminal interface
Changes by Tal Einat talei...@gmail.com: -- nosy: -taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2704 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1253] IDLE - Percolator overhaul
Tal Einat added the comment: This should be closed as wont fix. -- nosy: +taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1253 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6143] IDLE - an extension to clear the shell window
Changes by Tal Einat talei...@gmail.com: -- nosy: -taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6143 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1442493] IDLE shell window gets very slow when displaying long lines
Changes by Tal Einat talei...@gmail.com: -- nosy: -taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1442493 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1612262] Class Browser doesn't show internal classes
Changes by Tal Einat talei...@gmail.com: -- nosy: -taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1612262 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9262] IDLE: Use tabbed shell and edit windows
Changes by Tal Einat talei...@gmail.com: -- nosy: -taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9262 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3068] IDLE - Add an extension configuration dialog
Tal Einat added the comment: Is there any chance this patch could get some love? I've stopped using IDLE a long time ago, but this patch is a great improvement! -- versions: +Python 3.5 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3068 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10079] idlelib for Python 3 with Guilherme Polo GSoC enhancements
Changes by Tal Einat talei...@gmail.com: -- nosy: -taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10079 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6299] pyexpat build failure on Solaris 10 for 2.6.1/2.6.2
koobs added the comment: Adding a patch for reference only -- keywords: +patch Added file: http://bugs.python.org/file33902/python-issue6299.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6299 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20404] Delayed exception using non-text encodings with TextIOWrapper
Roundup Robot added the comment: New changeset f3ec00d2b75e by Nick Coghlan in branch 'default': Close #20404: blacklist non-text encodings in io.TextIOWrapper http://hg.python.org/cpython/rev/f3ec00d2b75e -- nosy: +python-dev resolution: - fixed stage: commit review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20404 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12411] cgi.parse_multipart is broken on 3.x
Changes by Tal Einat talei...@gmail.com: -- nosy: -taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12411 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6858] This is a python file, apply syntax highlighting
Tal Einat added the comment: Roger's patch LGTM, and should be considered a bug-fix. I will note, however, that this doesn't address the original issue: It still does not supply an easily discoverable method of toggling highlighting. Having a keyboard shortcut documented in the help file is necessary, but few novice users will ever notice it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6858 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20485] Enable 'import Non-ASCII.pyd'
Nick Coghlan added the comment: Oh, you're right - I temporarily forgot that the C runtime compatibility was compiler version specific on Windows. So such an approach *would* require updating the CPython compiler on Windows to at least VS2013 for 3.5. Still, we're likely to want to do that anyway - VS2010 will be as old in 2015 as VS2008 is now, and the latter is already causing hassles for building 2.7 extension modules. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20485 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19744] test_venv fails if SSL/TLS is not available
Changes by Nick Coghlan ncogh...@gmail.com: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19744 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20485] Enable 'import Non-ASCII.pyd'
Suzumizaki added the comment: Both Visual Studio 2012 and 2013 CANNOT install on Windows Vista. That's OK for you even Vista alive until April 2017? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20485 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16296] Patch to fix building on Win32/64 under VS 2010
Thomas Heller added the comment: Hm, what's the problem? For me, the patch applies cleanly (in Python 3.4.0b3, 32-bit and 64-bit on Windows), and py -3.4(-32) -m pip install numpy works correctly. At least py -3.4(-32) -c import numpy; print(numpy.__version__) prints 1.8.0. This is with the newest pip (1.5.2). I have the full version of visual studio 2010 installed. -- nosy: +theller ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20053] venv and ensurepip are affected by default pip config file
Roundup Robot added the comment: New changeset 1b8ba1346e67 by Nick Coghlan in branch 'default': Close #20053: ignore default pip config settings http://hg.python.org/cpython/rev/1b8ba1346e67 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20053 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20508] IndexError from ipaddress._BaseNetwork.__getitem__ has no message
New submission from Gareth Rees:
If you try to look up an out-of-range address from an object returned
by ipaddress.ip_network, then ipaddress._BaseNetwork.__getitem__
raises an IndexError with no message:
Python 3.4.0b3 (default, Jan 27 2014, 02:26:41)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
Type help, copyright, credits or license for more information.
import ipaddress
ipaddress.ip_network('2001:db8::8/125')[100]
Traceback (most recent call last):
File stdin, line 1, in module
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/ipaddress.py,
line 601, in __getitem__
raise IndexError
IndexError
Normally an IndexError is associated with a message explaining the
cause of the error. For example:
[].pop()
Traceback (most recent call last):
File stdin, line 1, in module
IndexError: pop from empty list
It would be nice if the IndexError from
ipaddress._BaseNetwork.__getitem__ included a message like this.
With the attached patch, the error message looks like this in the
positive case:
ipaddress.ip_network('2001:db8::8/125')[100]
Traceback (most recent call last):
File stdin, line 1, in module
File /Users/gdr/hg.python.org/cpython/Lib/ipaddress.py, line 602, in
__getitem__
% (self, self.num_addresses))
IndexError: 100 out of range 0..7 for 2001:db8::8/125
and like this in the negative case:
ipaddress.ip_network('2001:db8::8/125')[-100]
Traceback (most recent call last):
File stdin, line 1, in module
File /Users/gdr/hg.python.org/cpython/Lib/ipaddress.py, line 608, in
__getitem__
% (n - 1, self.num_addresses, self))
IndexError: -100 out of range -8..-1 for 2001:db8::8/125
(If you have a better suggestion for how the error message should
read, I could submit a revised patch. I suppose it could just say
address index out of range for consistency with list.__getitem__ and
str.__getitem__. But I think the extra information is likely to be
helpful for the programmer who is trying to track down the cause of an
error.)
--
components: Library (Lib)
files: ipaddress.patch
keywords: patch
messages: 210224
nosy: Gareth.Rees
priority: normal
severity: normal
status: open
title: IndexError from ipaddress._BaseNetwork.__getitem__ has no message
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33903/ipaddress.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20508
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20502] Context setting to print Decimal with as many digits as the prec setting
Mauricio de Alencar added the comment:
I propose then to create a context setting that switches between the current
textual representation of a Decimal and one that is right zeros padded up to
context precision.
Such that the line:
print(Context(prec=4, precise_repr=True).create_decimal_from_float(1.))
would output 1.000
I post bellow a workaround for getting the result I expect just in case there
is anybody else with similar expectations.
from decimal import Context
def dec(num, prec):
return Context(prec=prec).create_decimal('{{:.{:d}e}}'.format(prec -
1).format(num))
Thanks for you attention.
--
resolution: invalid -
status: closed - open
title: Context.create_decimal_from_float() inconsistent precision for zeros
after decimal mark - Context setting to print Decimal with as many digits as
the prec setting
type: behavior - enhancement
versions: -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20502
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6299] pyexpat build failure on Solaris 10 for 2.6.1/2.6.2
Changes by STINNER Victor victor.stin...@gmail.com: -- versions: -Python 2.6, Python 3.1, Python 3.2, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6299 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20502] Context setting to print Decimal with as many digits as the prec setting
Mark Dickinson added the comment:
If you're after a particular string representation, you'll probably find that
string formatting meets your needs.
Python 3.3.3 (default, Nov 24 2013, 14:34:37)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
Type help, copyright, credits or license for more information.
from decimal import Decimal
x = Decimal('3.3')
x
Decimal('3.3')
{:.4f}.format(x) # string representation with 4 digits after the point.
'3.3000'
Reclosing this issue. If you want to pursue your proposal, please open a
separate issue for that rather than reopening this one. Thanks!
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20502
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20502] Context setting to print Decimal with as many digits as the prec setting
Changes by Mark Dickinson dicki...@gmail.com: -- type: enhancement - behavior versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20502 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20508] IndexError from ipaddress._BaseNetwork.__getitem__ has no message
Changes by Gareth Rees g...@garethrees.org: -- type: behavior - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20508 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19362] Documentation for len() fails to mention that it works on sets
Gareth Rees added the comment: Here's a revised patch using Ezio's suggestion (Return the number of items of a sequence or container). -- Added file: http://bugs.python.org/file33904/len-set.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19362 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20502] Context.create_decimal_from_float() inconsistent precision for zeros after decimal mark
Changes by Mark Dickinson dicki...@gmail.com: -- title: Context setting to print Decimal with as many digits as the prec setting - Context.create_decimal_from_float() inconsistent precision for zeros after decimal mark ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20502 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19362] Documentation for len() fails to mention that it works on sets
Changes by Gareth Rees g...@garethrees.org: -- title: Documentation for len() fails to mention that it works on sets - Documentation for len() fails to mention that it works on sets versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19362 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20502] Context.create_decimal_from_float() inconsistent precision for zeros after decimal mark
Mauricio de Alencar added the comment: String formatting is completely unaware of the concept of *significant digits*. The only format that can get it right for every case is the 'e'. But then you always get the exponent, which is undesirable. I was hopeful that the decimal module would handle significant digits as I need. I will settle with the workaround I posted earlier. Thanks anyway. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20502 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20502] Context.create_decimal_from_float() inconsistent precision for zeros after decimal mark
Stefan Krah added the comment: Mauricio de Alencar rep...@bugs.python.org wrote: String formatting is completely unaware of the concept of *significant digits*. format(Decimal(1), .2f) '1.00' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20502 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16296] Patch to fix building on Win32/64 under VS 2010
Paul Moore added the comment: Maybe it's not applicable to 3.3 somehow, which is what I tried. I applied the patch to the distutils in the system installed Python, then ran pip install numpy from a virtualenv. It's quite possible that a million things could have gone wrong in that process - but that's all I had time to check (I'm only really interested in this as a courtesy to the numpy people, who asked me to raise the bug on numpy, then directed me to this patch as a fix). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20451] os.exec* mangles argv on windows (splits on spaces, etc)
R. David Murray added the comment: I believe the problem lies with the way that Windows implements the 'exec' functions. Windows isn't posix, and sometimes its attempts to fake it go rather badly. So, I'm not sure what the actual rules are, but whatever they are there should at least be a mention/pointer in the documentation about it. Really, if you want to be cross platform you should use subprocess. exec doesn't really even exec (replace the current process) on windows, if I understand correctly. By the way, -c accepts strings with embedded newlines, something I didn't know for a long time :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20451 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20502] Context.create_decimal_from_float() inconsistent precision for zeros after decimal mark
Mauricio de Alencar added the comment:
Digits after the decimal mark is not the same as significant digits.
See https://en.wikipedia.org/wiki/Significant_figures
If I have a list of numbers [256.2, 1.3, 0.5] that have 3 significant digits
each, I would like to have them displayed as:
['256', '1.30', '0.500']
['{:.2e}'.format(_) for _ in [256.2, 1.3, 0.5]]
would print:
['2.56e+02', '1.30e+00', '5.00e-01']
Which gets the digits right, but is not as desired.
But if I use
from decimal import Context
def dec(num, prec):
return Context(prec=prec).create_decimal('{{:.{:d}e}}'.format(prec -
1).format(num))
[str(dec(_, 3)) for _ in [256.2, 1.3, 0.5]]
The the output is:
['256', '1.30', '0.500']
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20502
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1654367] [PATCH] Debuggers need a way to change the locals of a frame
Fabio Zadrozny added the comment: Just a note for anyone interested: ctypes can be used to access that function: http://pydev.blogspot.com.br/2014/02/changing-locals-of-frame-frameflocals.html So, I think that the changes I proposed shouldn't be applied (it'd only be worth if someone provided an implementation that did frame.f_locals writable...). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1654367 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files
Zachary Ware added the comment: Ok, so my changes to CONVERT_TO_DOUBLE don't fly with gcc, so that's out. In the two cases where convert_to_double wants a PyObject *, we could declare PyObject *objself = (PyObject *)self;, but that's not particularly appealing. I'll leave the whole PyObject vs. PyFloatObject issue to someone with more C experience. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20185 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20502] Context.create_decimal_from_float() inconsistent precision for zeros after decimal mark
Stefan Krah added the comment: Mauricio de Alencar rep...@bugs.python.org wrote: Mauricio de Alencar added the comment: Digits after the decimal mark is not the same as significant digits. See https://en.wikipedia.org/wiki/Significant_figures If I have a list of numbers [256.2, 1.3, 0.5] that have 3 significant digits each, I would like to have them displayed as: ['256', '1.30', '0.500'] You need to stop lecturing. The above sentence you wrote directly contradicts the Wikipedia link you have thrown at us. And yes, thank you, we do know what significant figures are. FYI, the Python implementation of decimal, the C implementation of decimal and decNumber are completely separate implementations of http://speleotrove.com/decimal/decarith.html by different authors and produce exactly the results that you criticize. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20502 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19186] expat symbols should be namespaced in pyexpat again
Lukas Vacek added the comment: attaching patch -- keywords: +patch nosy: +Lukas.Vacek Added file: http://bugs.python.org/file33905/fix_expat_names.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19186 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20481] Clarify type coercion rules in statistics module
Oscar Benjamin added the comment: I was working on the basis that we were talking about Python 3.5. But now I see that it's a 3.4 release blocker. Is it really that urgent? I think the current behaviour is very good at handling a wide range of types. It would be nice to consistently report errors for incompatible types but it can also just be documented as a thing that users shouldn't do. If there were a situation where it silently returned a highly inaccurate value I would consider that urgent but I don't think there is. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20481 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20506] Command to display all available Import Library
Brett Cannon added the comment:
The trick would be how to query finders to say what could you find? There is
no API for that so either something pragmatic that won't work in the face of
e.g. zipfiles would need to be used or a new optional API on finders to list
what the tail name of modules it can find are (but without the package name as
most finders just use fullname.rpartition('.')[-1] to figure out what they are
looking for).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20506
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20481] Clarify type coercion rules in statistics module
Nick Coghlan added the comment: Changing the behaviour is not urgent - documenting that it may change in the future is essential. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20481 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19186] expat symbols should be namespaced in pyexpat again
Roundup Robot added the comment: New changeset c242a8f30806 by Benjamin Peterson in branch '3.3': restore namespacing of pyexpat symbols (closes #19186) http://hg.python.org/cpython/rev/c242a8f30806 New changeset a2d877fb53f6 by Benjamin Peterson in branch 'default': merge 3.3 (#19186) http://hg.python.org/cpython/rev/a2d877fb53f6 -- nosy: +python-dev resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19186 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20494] Backport of http://bugs.python.org/issue11849 to Python 2.7 (Make it more likely for the system allocator to release free()d memory arenas on glibc-based systems).
Roundup Robot added the comment: New changeset 4e43e5b3f7fc by Benjamin Peterson in branch '2.7': mmap obmalloc arenas so that they may be immediately returned to the system when unused (closes #20494) http://hg.python.org/cpython/rev/4e43e5b3f7fc -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14376] sys.exit documents argument as integer but actually requires subtype of int
Gareth Rees added the comment: Patch attached. I added a test case to Lib/test/test_sys.py. -- Added file: http://bugs.python.org/file33906/exit.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14376 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20481] Clarify type coercion rules in statistics module
Wolfgang Maier added the comment: Hi Nick and Oscar, my patch including tests is ready. What else should I say than that I think it is ok, but of course with only days remaining and still no feedback from Steven, I'm not sure there is any chance for it going into 3.4 still. Anyway, before uploading I wanted to ask you what the best procedure is: upload the module and its tests as one diff or separately so that it is easier to see where the current module version fails? Best, Wolfgang -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20481 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20502] Context.create_decimal_from_float() inconsistent precision for zeros after decimal mark
Mauricio de Alencar added the comment: You need to stop lecturing. I'm sorry, I didn't mean to offend anyone. I just felt I was failing to communicate the issue when I got the suggestion to use format(Decimal(1), .2f). The above sentence you wrote directly contradicts the Wikipedia link you have thrown at us. The floats I posted are examples of computation results. The meaningful figures are related to the precision of the measurements fed to the computation. by different authors and produce exactly the results that you criticize. I understand the design choice for decimal. I just miss a pythonic way of dealing with significant figures. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20502 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20509] logging.config.fileConfig() docs could link to the config file format
New submission from Marius Gedminas: When one is reading the description of logging.config.fileConfig() at http://docs.python.org/3.3/library/logging.config.html#logging.config.fileConfig not immediately apparent what the configparser-format file should contain (i.e. the naming convention for sections, and what keys mean what.) This is all nicely described at http://docs.python.org/3.3/library/logging.config.html#configuration-file-format but personal experience shows that users like me hit Page Down a few times and give up before they reach that part (and also they do not think to read the outline in the sidebar). It would be nice if there was a direct link, like in the attached patch. -- assignee: docs@python components: Documentation files: improve-fileconfig-docs.patch keywords: patch messages: 210245 nosy: docs@python, mgedmin priority: normal severity: normal status: open title: logging.config.fileConfig() docs could link to the config file format type: enhancement versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file33907/improve-fileconfig-docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20509 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20510] Test cases in test_sys don't match the comments
New submission from Gareth Rees: Lib/test/test_sys.py contains test cases with incorrect comments -- or comments with incorrect test cases, if you prefer: # call without argument try: sys.exit(0) except SystemExit as exc: self.assertEqual(exc.code, 0) ... # call with tuple argument with one entry # entry will be unpacked try: sys.exit(42) except SystemExit as exc: self.assertEqual(exc.code, 42) ... # call with integer argument try: sys.exit((42,)) except SystemExit as exc: self.assertEqual(exc.code, 42) ... (In the quote above I've edited out some inessential detail; see the file if you really want to know.) You can see that in the first test case sys.exit is called with an argument (although the comment claims otherwise); in the second it is called with an integer (not a tuple), and in the third it is called with a tuple (not an integer). These comments have been unchanged since the original commit by Walter Dörwald http://hg.python.org/cpython/rev/6a1394660270. I've attached a patch that corrects the first test case and swaps the comments for the second and third test cases: # call without argument rc = subprocess.call([sys.executable, -c, import sys; sys.exit()]) self.assertEqual(rc, 0) # call with integer argument try: sys.exit(42) except SystemExit as exc: self.assertEqual(exc.code, 42) ... # call with tuple argument with one entry # entry will be unpacked try: sys.exit((42,)) except SystemExit as exc: self.assertEqual(exc.code, 42) ... Note that in the first test case (without an argument) sys.exit() with no argument actually raises SystemExit(None), so it's not sufficient to catch the SystemExit and check exc.code; I need to check that it actually gets translated to 0 on exit. -- components: Tests files: exittest.patch keywords: patch messages: 210246 nosy: Gareth.Rees priority: normal severity: normal status: open title: Test cases in test_sys don't match the comments type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file33908/exittest.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20510 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20509] logging.config.fileConfig() docs could link to the config file format
Changes by Vinay Sajip vinay_sa...@yahoo.co.uk: -- assignee: docs@python - vinay.sajip nosy: +vinay.sajip versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20509 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20481] Clarify type coercion rules in statistics module
Steven D'Aprano added the comment: Wolfgang, Thanks for the patch, I have some concerns about it, but the basic idea does look reasonable. However, I've been convinced that supporting mixed types at all needs more careful thought. Under the circumstances, I'm more concerned about making sure we don't lock in any behaviour we'll regret, so for 3.4 I'm going to follow Nick's advice and reject mixed-type calculations. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20481 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20509] logging.config.fileConfig() docs could link to the config file format
Roundup Robot added the comment: New changeset 45aa817ec853 by Vinay Sajip in branch '2.7': Issue #20509: Added cross-reference in documentation. http://hg.python.org/cpython/rev/45aa817ec853 New changeset f8318b069146 by Vinay Sajip in branch '3.3': Issue #20509: Added cross-reference in documentation. http://hg.python.org/cpython/rev/f8318b069146 New changeset 7d0a4f89c6ce by Vinay Sajip in branch 'default': Closes #20509: Merged documentation update from 3.3. http://hg.python.org/cpython/rev/7d0a4f89c6ce -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20509 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20481] Clarify type coercion rules in statistics module
Wolfgang Maier added the comment: Hi Steven, sounds reasonable, still here's the patch in diff version. Its rules for type coercion are detailed in _coerce_types's docstring. Questions and comments are welcome. Best, Wolfgang -- keywords: +patch Added file: http://bugs.python.org/file33910/statistics.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20481 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19363] Python 2.7's future_builtins.map is not compatible with Python 3's map
Gareth Rees added the comment: What about a documentation change instead? The future_builtins chapter http://docs.python.org/2/library/future_builtins.html in the standard library documentation could note the incompatibility. I've attached a patch which adds the following note to the documentation for future_builtins.map: Note: In Python 3, map() does not accept None for the function argument. (zip() can be used instead.) -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19363 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20510] Test cases in test_sys don't match the comments
Changes by Zachary Ware zachary.w...@gmail.com: -- nosy: +zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20510 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20510] Test cases in test_sys don't match the comments
Zachary Ware added the comment: Good catch! See my review comments. Also, if you haven't already, could you please sign a contributor's agreement? See http://www.python.org/psf/contrib/. -- stage: - patch review versions: +Python 2.7, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20510 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20491] textwrap: Non-breaking space not honored
Changes by Kaarle Ritvanen kaarle.ritva...@datakunkku.fi: Added file: http://bugs.python.org/file33911/honor-non-breaking-spaces.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20491 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20511] asyncio: StreamReader should use bytearray for its internal buffer
New submission from Yury Selivanov: This issue on google code: https://code.google.com/p/tulip/issues/detail?id=124 -- files: sr_ba_01.patch keywords: needs review, patch messages: 210253 nosy: gvanrossum, haypo, pitrou, yselivanov priority: normal severity: normal status: open title: asyncio: StreamReader should use bytearray for its internal buffer Added file: http://bugs.python.org/file33912/sr_ba_01.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20511 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20502] Context.create_decimal_from_float() inconsistent precision for zeros after decimal mark
Stefan Krah added the comment:
Mauricio de Alencar rep...@bugs.python.org wrote:
The floats I posted are examples of computation results. The meaningful
figures are related to the precision of the measurements fed to the
computation.
Thank you, that makes it clear. Constructing Decimal('256.2') preserves
the exact value, regardless of the context precision. All arithmetic
functions accept arbitrary precision input and use all digits regardless
of the context precision.
To put it differently, decimal refuses to guess and treats any input
as having the correct number of significant digits.
If you want to attribute a significance to a series of input numbers,
I guess you have to do it manually, using something like:
def mk_full_coeff(x):
prec = getcontext().prec
adj = x.adjusted()
if adj = prec:
return +x
else:
return x.quantize(Decimal(1).scaleb(adj-prec+1))
c = getcontext()
c.prec = 3
[mk_full_coeff(x) for x in [Decimal('256.2'), Decimal('1.3'),
Decimal('0.5')]]
[Decimal('256'), Decimal('1.30'), Decimal('0.500')]
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20502
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19573] Fix the docstring of inspect.Parameter and the implementation of _ParameterKind
Antony Lee added the comment: Submitted new patch as suggested. -- Added file: http://bugs.python.org/file33913/inspect.py.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19573 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19573] Fix the docstring of inspect.Parameter and the implementation of _ParameterKind
Yury Selivanov added the comment: The patch looks good to me. I'll merge it in 3.5 later. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19573 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20510] Test cases in test_sys don't match the comments
Gareth Rees added the comment: I normally try not to make changes while we're in here for fear of introducing errors! But I guess the test cases are less critical, so I've taken your review comments as a license to submit a revised patch that: * incorporates your suggestion to use assert_python_ok from test.script_helper, instead of subprocess.call; * replaces the other uses of subprocess.call with assert_python_failure and adds a check on stdout; * cleans up the assertion-testing code using the context manager form of unittest.TestCase.assertRaises. I've signed and submitted a contributor agreement as requested. -- Added file: http://bugs.python.org/file33914/exittest-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20510 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20512] Python3.3 segfaults when using big5hkscs encoding
New submission from Alexis Daboville:
When using the 'big5hkscs' encoding it's possible to make Python3.3 segfault,
here is how to repro:
✗ 13:41 adaboville @ adoboville-mbp in ~ $ py3
Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type help, copyright, credits or license for more information.
'nb'.encode('big5hkscs')
b'nb'
'nb'.encode('big5hkscs')
Segmentation fault: 11
Note that it doesn't crash on the first first line, but on the second (even
though both lines are the same). FWIW pypy3.3 doesn't crash:
✓ 13:43 adaboville @ adoboville-mbp in .../pypy3-2.1-beta1-osx64 $ bin/pypy
Python 3.2.3 (d63636b30cc0, Jul 30 2013, 07:02:48)
[PyPy 2.1.0-beta1 with GCC 4.2.1 Compatible Clang Compiler] on darwin
Type help, copyright, credits or license for more information.
And now for something completely different: ``why did you guys have to make the
builtin fortune more interesting than actual work? i just catched myself
restarting pypy 20 times''
'nb'.encode('big5hkscs')
b'nb'
'nb'.encode('big5hkscs')
b'nb'
--
messages: 210258
nosy: alexis.d
priority: normal
severity: normal
status: open
title: Python3.3 segfaults when using big5hkscs encoding
type: crash
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20512
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20512] Python3.3 segfaults when using big5hkscs encoding
Yury Selivanov added the comment: Can't reproduce this on 3.3.3 Python 3.3.3 (default, Dec 2 2013, 01:40:21) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin -- nosy: +yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20512 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20513] Script interruption on logoff from 0 session under Win2003 and earlier
New submission from Victor Scherba: To get the bug: 1. Windows Server 2003 (same bug should be under earlier versions: XP, 2000, ...). 2. Any Windows service should spawn process with Python script. 3. Py script should stay into time.sleep. 4. Any Windows user should login in console session 0. 5. Bug: when this user logoff, script interrupts. To repeat the bug simply you could use srvany which spawn: python.exe -c import time; time.sleep(1). There is problem in cpython/Modules/timemodule.c in PyCtrlHandler. Before logoff Windows broadcasts to all services and its children CTRL_LOGOFF_EVENT signal. But PyCtrlHandler doesn't filter it out by dwCtrlType and always sets hInterruptEvent. This forces script interruption. CTRL_SHUTDOWN_EVENT also should be filtered out. CTRL_SHUTDOWN_EVENT broacasted to all services before Windows shutdown. But after it has been handled, other process can block or pause shutdowning. Default Windows console control handler does not call ExitProcess when processing the CTRL_LOGOFF_EVENT and CTRL_SHUTDOWN_EVENT signals. See more at http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx On Win Vista and higher bug not presents. Impossible to login to session 0 because of session 0 isolation. Patch attached. There is same fix in cpython/Modules/_multiprocessing/multiprocessing.c -- components: Extension Modules, Windows messages: 210259 nosy: vScherba priority: normal severity: normal status: open title: Script interruption on logoff from 0 session under Win2003 and earlier type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20513 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
