[issue24883] Typo in c-api/buffer documentation
New submission from TAKASE Arihiro: https://docs.python.org/3/c-api/buffer.html Some links to the members of Py_buffer are not available. ~Py_Buffer should be ~Py_buffer. The attached patch fixes it. -- assignee: docs@python components: Documentation files: bufferdoc.patch keywords: patch messages: 248758 nosy: artakase, docs@python priority: normal severity: normal status: open title: Typo in c-api/buffer documentation type: behavior versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40200/bufferdoc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24883 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24880] ctypeslib patch for regular expression for symbols to include
Changes by Ronald Oussoren ronaldousso...@mac.com: -- nosy: +theller ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24880 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24880] ctypeslib patch for regular expression for symbols to include
Ronald Oussoren added the comment: This appears to be an issue for an external library https://pypi.python.org/pypi/ctypeslib, although one hosted at svn.python.org. -- nosy: +ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24880 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24879] Pydoc to list data descriptors in _fields order if it exists
Raymond Hettinger added the comment: Named tuples are not a type, they are a protocol. Guido has agreed that checking for _fields is an acceptable and preferred way of finding out whether something is a namedtuple.I can add a check to at least check the value of _fields is an iterable of strings. If it still aliases with some random use of _fields, the only consequence is that the matching field names will appear in a different order. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24879 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation
Ned Deily added the comment: Thanks for all of your contributions on this. I've committed a version along the lines I suggested along with Martin's example. -- resolution: - fixed stage: commit review - resolved status: open - closed type: behavior - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24079 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation
Roundup Robot added the comment: New changeset d3cda8cf4d42 by Ned Deily in branch '2.7': Issue #24079: Improve description of the text and tail attributes for https://hg.python.org/cpython/rev/d3cda8cf4d42 New changeset ad0491f85050 by Ned Deily in branch '3.4': Issue #24079: Improve description of the text and tail attributes for https://hg.python.org/cpython/rev/ad0491f85050 New changeset 17ce3486fd8f by Ned Deily in branch '3.5': Issue #24079: merge from 3.4 https://hg.python.org/cpython/rev/17ce3486fd8f New changeset 3c94ece57c43 by Ned Deily in branch 'default': Issue #24079: merge from 3.5 https://hg.python.org/cpython/rev/3c94ece57c43 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24079 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24769] Interpreter doesn't start when dynamic loading is disabled
Robert Collins added the comment: Patch looks good to me too. I think this needs to be put forward as a PR to bitbucket right? It looks Release Critical to me. -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24769 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24305] The new import system makes it impossible to correctly issue a deprecation warning for a module
Brett Cannon added the comment: Here is a new version of the patch with Nathaniel's and and Berker's comments addressed. -- Added file: http://bugs.python.org/file40199/issue24305.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24305 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24847] Can't import tkinter in Python 3.5.0rc1
Robert Collins added the comment: Looks good to me. I think you should commit (or perhaps you are pending PR approval on the rc branch or something?) -- nosy: +rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24847 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24879] Pydoc to list data descriptors in _fields order if it exists
Yury Selivanov added the comment: Named tuples are not a type, they are a protocol. Guido has agreed that checking for _fields is an acceptable and preferred way of finding out whether something is a namedtuple. They are, but for protocols we usually use dunder names. _fields is a common enough attribute name for all kinds of objects, not necessarily namedtuples. Can we at least check if the class is a tuple subclass and then use its '_fields' for sorting? I can add a check to at least check the value of _fields is an iterable of strings. If it still aliases with some random use of _fields, the only consequence is that the matching field names will appear in a different order. +1 for checking if it's an iterable of strings. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24879 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
New submission from Cosimo Lupo: the `_pyio` module at line 16 tries to check whether it is running on Windows platform, by doing: ``` if os.name == 'win32': from msvcrt import setmode as _setmode else: _setmode = None ``` However, the string returned by os.name is 'nt' and not 'win32' (the latter is returned by `sys.platform`). Therefore, the value is always False and the setmode function from mscvrt module is never imported. Thank you. Cheers, Cosimo -- components: IO messages: 248728 nosy: Cosimo Lupo priority: normal severity: normal status: open title: _pyio checks that `os.name == 'win32'` instead of 'nt' type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24881 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24764] cgi.FieldStorage can't parse multipart part headers with Content-Length and no filename in Content-Disposition
Peter Landry added the comment: Pradeep, that error seems to be in Barbican. This bug and patch only addresses content-length headers in MIME multipart messages. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Marc-Andre Lemburg added the comment: If I understand you correctly, the only advantage of using /MT is not require admin privileges for installation of the VC2015 runtime libs. Since VC2015 will be used by a lot of applications in a few months, and it's likely that MS will ship the runtime as Windows update anyway, the advantage seems minor. OTOH, the requirement of linking against external libraries which you cannot recompile or don't support /MT is rather common and won't go away. And the need for security updates to the ucrt is rather inevitable as well based on experience with previous CRTs. Being able to build a statically linked Python binary is a nice feature for some special application settings, but given the rather weak arguments for making this the default, I'm not convinced that this is a good way forward, esp. not when even MS itself recommends against doing this. We can have Python run VCredist during the installation to make sure the runtime DLLs are available. Then no one will have a problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24746] doctest 'fancy diff' formats incorrectly strip trailing whitespace
Jairo Trad added the comment: I can write a unittest for this, where should I write it? a new test file? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24746 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24746] doctest 'fancy diff' formats incorrectly strip trailing whitespace
R. David Murray added the comment: I believe you can put it in the test_doctest file, and call it using the appropriate runner from test.support from the test_main function. I haven't tried it though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24746 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Ryan Gonzalez added the comment: Wait, did you compile this with Clang? On August 17, 2015 9:24:50 AM CDT, Cyd Haselton rep...@bugs.python.org wrote: Cyd Haselton added the comment: Result: (gdb) bt #0 0xb6a63cc8 in ?? () #1 0xb6a5feb0 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Cyd Haselton added the comment: Result: (gdb) bt #0 0xb6a63cc8 in ?? () #1 0xb6a5feb0 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24881] _pyio checks that `os.name == 'win32'` instead of 'nt'
Changes by Zachary Ware zachary.w...@gmail.com: -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware versions: +Python 3.4, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24881 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Steve Dower added the comment: Unfortunately applocal deployment doesn't solve the versioning issue - you'll always need to use VS 2015 to build for Python 3.5. There are only a few more libraries that are affected by /MT. msvcp140.dll is the most likely one here. Doing the same /nodefaultlib dance for that might work, but it may not. All of the shared state like memory allocation and file descriptors are in ucrt, which will not change with compiler versions. CPython itself does not require any extensions to use VS 2015 as long as they link to ucrtbase and not another CRT, but it's looking like the same build process won't work everywhere else. Installing the full runtime requires administrative privileges, and removing that requirement was one of the priorities. If certain extensions require it or if distros install it that's fine, but I don't want distutils to *help* people make wheels that won't work on another machine because the runtime isn't there. Depending on the size difference, statically linking the C++ parts may not be so bad. It's certainly no worse than including it local to Python, and all of its potentially shared state should be handled by the ucrt already. Also, I've already had that OpenSSL issue fixed upstream. You must have an older version - I've been building it fine without patching for months now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24878] Add docstrings to selected named tuples
Roundup Robot added the comment: New changeset 40f2bbb922e6 by Raymond Hettinger in branch 'default': Issue #24878: Add docstrings to selected namedtuples https://hg.python.org/cpython/rev/40f2bbb922e6 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24878 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24847] Can't import tkinter in Python 3.5.0rc1
Steve Dower added the comment: I'll withdraw my current pull request and make a new one tomorrow. I prefer to check into 3.5.1 immediately, and especially since this one will be covered by the buildbots, so I'll do that first. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24847 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24878] Add docstrings to selected named tuples
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24878 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24882] ThreadPoolExceutor doesn't reuse threads until #threads == max_workers
New submission from Matt Spitz: https://hg.python.org/cpython/file/3.4/Lib/concurrent/futures/thread.py#l114 ThreadPoolExecutor will keep spawning new threads, even if existing threads are waiting for new work. We should check against the queue length when deciding to spawn a new thread to avoid creating unnecessary threads. -- messages: 248732 nosy: Matt Spitz priority: normal severity: normal status: open title: ThreadPoolExceutor doesn't reuse threads until #threads == max_workers type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24882 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24781] Improve UX of IDLE Highlighting configuration tab
Mark Roseman added the comment: I am admittedly not a fan of skinnable user interfaces, especially for non-entertainment applications. It doesn't add anything to the usability, and makes support harder. It always says to me hello, 2002 called and wants it's user interface back. I think the actual changing themes part of ttk is the least useful piece. However, I've no grand objection to adding a setting in the general pane for this, perhaps called User Interface Skin. I'm still very fond of themes for the syntax coloring tab. The two most commonly used terms seem to be themes (e.g. TextMate, Eclipse), and color schemes (e.g. Sublime, UltraEdit). On the matter of changing background color, what I mean is that to modify the background color so that e.g. it's off-white instead of white, you need to change I think it's nine different theme elements. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24781 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24776] Improve Fonts/Tabs UX for IDLE
Terry J. Reedy added the comment: I agree. Cntl/Cmd +/- font sizing works in turtledemo within sensible limits. The code could be copied. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24781] Improve UX of IDLE Highlighting configuration tab
Terry J. Reedy added the comment: So you mean text background as opposed to widget background. I changed the background of non-user-entered shell, stdout, and stderr text in my personal highlight theme to light versions of the foreground, and like the result so much I have considered proposing changing the defaults. The result in Shell is to separate user entries from prompts and output and the latter three from each other. This leaves the 6 user-entry text items with white background. This would be helpful since most people would want all 6 backgrounds in the editor the same and it is tedious to get all 6 the same 1 at a time and even worse to experiment with different settings. The explanation might be a bit tricky, but the idea is simple enough once seen. However, I would not want the individualized colors for non-user text altered. It seems that you want to be able to collectively define 'background white' to an off-white that would either apply to all user-entered -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24781 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24878] Add docstrings to selected named tuples
Changes by Raymond Hettinger raymond.hettin...@gmail.com: Added file: http://bugs.python.org/file40197/ntdoc2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24878 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24782] Merge 'configure extensions' into main IDLE config dialog
Mark Roseman added the comment: Yes that should be good to go -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24782 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24776] Improve Fonts/Tabs UX for IDLE
Mark Roseman added the comment: Agree about the font resizing menu items/shortcuts... your original #17642 remains open for this -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24877] Bad Password for file using zipfile module
Changes by shiva prasanth kesavarapu.s...@gmail.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24877 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24790] Idle: improve stack viewer
Can İbanoğlu added the comment: Hello, I'm very interested in tackling this issue but this will be my first contribution to Python and I'm quite nervous. I have gone over the developer guide and FAQ but I would appreciate if you could let me know if I should approach this in a certain way. -- nosy: +Can İbanoğlu ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24790 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24797] email.header.decode_header return type is not consistent
R. David Murray added the comment: Right, it's provisional in 3.4. I'm working on the doc rewrite now (although I suppose there's a chance it won't get accepted for 3.5, I expect it to). Take a look at https://docs.python.org/3/library/email.policy.html. Basically, if you use EmailMessage instead of Message (and therefore policy.default instead of policy.compat32) header parsing and decoding is handled for you. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24797 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24877] Bad Password for file using zipfile module
Changes by shiva prasanth kesavarapu.s...@gmail.com: -- type: - compile error versions: +Python 3.5 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24877 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24797] email.header.decode_header return type is not consistent
Sebastian Kreft added the comment: And what would the new API be? There is nothing pointing to it either in the documentation https://docs.python.org/3.4/library/email.header.html or source code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24797 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23003] traceback.{print_exc, print_exception, format_exc, format_exception}: Potential AttributeError
Changes by STINNER Victor victor.stin...@gmail.com: -- superseder: - traceback: add a new thin class storing a traceback without storing local variables ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23003 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23496] Steps for Android Native Build of Python 3.4.2
Cyd Haselton added the comment: No...compiled with GCC 4.9.2 On August 17, 2015 9:39:55 AM CDT, Ryan Gonzalez rep...@bugs.python.org wrote: Ryan Gonzalez added the comment: Wait, did you compile this with Clang? On August 17, 2015 9:24:50 AM CDT, Cyd Haselton rep...@bugs.python.org wrote: Cyd Haselton added the comment: Result: (gdb) bt #0 0xb6a63cc8 in ?? () #1 0xb6a5feb0 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23496 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Steve Dower added the comment: We can't have Python run VCredist because it requires administrative privileges and installing Python does not require those. This is actually one of the biggest complaints about the current installer, but because it looks like the design and not a bug it only comes up when you ask people directly what they'd like to change. (The most common bug is pip failing to install/uninstall, which is what you see on the issue tracker.) The other benefits are that PYDs compiled with VS 2016+ (or whatever it's called) with these options will work with stock Python 3.5 on a clean machine - so if your extension links to python3.dll you can build once for all Python versions 3.5 and later and know that it will just copy and run. If you're building from source and only have a newer compiler than VC14, you will be able to build successfully. Also, we could decide to build some future Python 3.5.x with a newer compiler as it should not break any existing extensions (after much discussion and testing, obviously, but it is only feasible if we properly hide the VC version now). To achieve these (apart from the last point) with VCredist, we need to be installing the current and all future versions of the redist with Python. Hence a time machine is required, and I haven't come up with any good way to simulate a time machine here. not when even MS itself recommends against doing this. I have separate advice (also from MS, from the same people who have been quoted previously, but in private conversations so I can't link to it) that if we want any chance of our plugin architecture being VC version independent, this is what we have to do. I'm emailing again to get more specific advice, but the official guidance has always been biased by wanting people to get the latest tools (which is why VC9 disappeared until my team made the case that sometimes people can't upgrade). We're still pushing hard to make this an acknowledged use case, and don't be surprised if at some point in the future official advice says if you allow plugins, do what CPython did to help your users and developers. The /MT == statically linked equivalence is an oversimplification in the presence of link-time code generation (/GL and /LTCG options), as we can take .obj or .lib files compiled with /MT and still use dynamic linking. The difference is we have to do it explicitly, which is what the /nodefaultlib:libucrt.lib ucrt.lib options do. If we add concrt140, msvcp140 and vccorlib140 to that as well (and probably the rest of the versions redistributables) then all of them will continue to be dynamically linked. So basically, all the existing static libs could be built with /MT and still have their dependencies dynamically linked if that's what the final linker decides to do. In any case, they probably need to be rebuilt with VC14 unless the authors have very carefully kept a clean API, in which case it may as well be a DLL. Because we're talking about a plugin architecture here, I think it's actually advantageous to use static linking of the C++ runtime. The main difference from the C runtime is that the C++ runtime does not have to be shared with the host - Python - and the advantage is that state will not be shared with other plugins that also happen to use the same version of C++ (or worse, a different version with the same name, and now we have a conflict). I appreciate the problems this causes when trying to link in 3rd-party dependencies, but given a choice between making life easier for developers or users I have to side with the users (while doing as much as I possibly can to make developers lives easier). People installing wheels from Christoph's page or PyPI should be able to expect it to work. When pip grows extensions I'll certainly look into writing an extension for specifying, detecting and getting the required VC redistributable, but I don't want core Python to be burdened with shipping the full set of distributables. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Marc-Andre Lemburg added the comment: On 17.08.2015 18:24, Steve Dower wrote: We can't have Python run VCredist because it requires administrative privileges and installing Python does not require those. This is actually one of the biggest complaints about the current installer, but because it looks like the design and not a bug it only comes up when you ask people directly what they'd like to change. (The most common bug is pip failing to install/uninstall, which is what you see on the issue tracker.) Why not ? People certainly trust the Python installer more than some script which might want to do this afterwards in order to get a package working. After all, it's signed by the PSF and comes with certificate backed verification of authenticity. The other benefits are that PYDs compiled with VS 2016+ (or whatever it's called) with these options will work with stock Python 3.5 on a clean machine - so if your extension links to python3.dll you can build once for all Python versions 3.5 and later and know that it will just copy and run. If you're building from source and only have a newer compiler than VC14, you will be able to build successfully. Also, we could decide to build some future Python 3.5.x with a newer compiler as it should not break any existing extensions (after much discussion and testing, obviously, but it is only feasible if we properly hide the VC version now). This would only work for extensions using the stable Python ABI. The standard approach is to rebuild extension for every minor release, since the standard Python ABI is not guaranteed to stay backwards compatible. To achieve these (apart from the last point) with VCredist, we need to be installing the current and all future versions of the redist with Python. Hence a time machine is required, and I haven't come up with any good way to simulate a time machine here. See above. This is really not a very common use case. If you search for Py_LIMITED_API (which has to be defined to enable the stable ABI), you'll hardly find any reference to code using it. not when even MS itself recommends against doing this. I have separate advice (also from MS, from the same people who have been quoted previously, but in private conversations so I can't link to it) that if we want any chance of our plugin architecture being VC version independent, this is what we have to do. I'm emailing again to get more specific advice, but the official guidance has always been biased by wanting people to get the latest tools (which is why VC9 disappeared until my team made the case that sometimes people can't upgrade). We're still pushing hard to make this an acknowledged use case, and don't be surprised if at some point in the future official advice says if you allow plugins, do what CPython did to help your users and developers. Regardless of marketing strategies, the fact that you have to reinstall Python and all extensions in case there's some bug in the CRT is really the main argument against doing static linking. Static linking of the CRT is normally only used in situations where you don't want to have single file executables without external dependencies, e.g. for working on arbitrary Windows systems without having to install anything. It's a valid use case, but not a general purpose one. The /MT == statically linked equivalence is an oversimplification in the presence of link-time code generation (/GL and /LTCG options), as we can take .obj or .lib files compiled with /MT and still use dynamic linking. The difference is we have to do it explicitly, which is what the /nodefaultlib:libucrt.lib ucrt.lib options do. If we add concrt140, msvcp140 and vccorlib140 to that as well (and probably the rest of the versions redistributables) then all of them will continue to be dynamically linked. So basically, all the existing static libs could be built with /MT and still have their dependencies dynamically linked if that's what the final linker decides to do. In any case, they probably need to be rebuilt with VC14 unless the authors have very carefully kept a clean API, in which case it may as well be a DLL. You lost me there. What's the advantage of using /MT when you then add all of the CRT libs to the set of libs which are dynamically linked ? Just to clarify: If I want to ship a C extension compiled for Python 3.5 which links to an external DLL on the system, I will have to tell the users of the extension to first run VCredist in order for them to be able to use extension on their system, since Python 3.5 will not ship with the necessary CRT DLLs, correct ? Because we're talking about a plugin architecture here, I think it's actually advantageous to use static linking of the C++ runtime. The main difference from the C runtime is that the C++ runtime does not have to be shared with the host - Python - and the advantage is that state will not be shared with
[issue24790] Idle: improve stack viewer
Can İbanoğlu added the comment: It does indeed, thank you very much! I have signed the Contributor Agreement and will start working on this right away. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24790 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24790] Idle: improve stack viewer
Terry J. Reedy added the comment: Welcome. I was hoping a new contributor would see the 'easy' tag. Nervous is okay as long as it leads to heighten carefulness without paralysis. I am still nervous hitting the [Commit] button. 1. Important. Sign the contributor agreement. https://www.python.org/psf/contrib/ https://www.python.org/psf/contrib/contrib-form/ I will not look at a patch until you say you have signed. I will not commit until the '*' appears on your name (perhaps a week). 2. Once you sign, I will give you at least a week to produce something before I work on this by myself. Patch needs to apply to 3.4, but StackViewer.py should be identical for 3.4/5/6. 3. Post a patch as soon as you do a complete chunk (any of the numbered items). Start with either 1. or 2. and switch if you get stuck. Does above answer your question? -- assignee: - terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24790 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24879] Pydoc to list data descriptors in _fields order if it exists
Yury Selivanov added the comment: Can this be enabled only for namedtuples? Otherwise this might be a backwards incompatible change, for example: class Foo: '''spam''' _fields = None -- nosy: +yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24879 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24880] ctypeslib patch for regular expression for symbols to include
New submission from Jan Wagner: There is an issue in ctypeslib that affects xml2py.py option -r. The usage informs that -r EXPRESSION regular expression for symbols to include. However, when the expression is evaluated, only exact name matches are actually selected. For example, -r set would match only a function called set. The underlying issue is in codegenerator.py. Here is a small patch that changes the behaviour of codegenerator.py so that it (and xml2py.py) are more consistent with the usage instructions. With the patch, -r set will match all functions containing set, e.g., setData, setAxis, and so on. -- components: ctypes files: codegenerator.patch keywords: patch messages: 248721 nosy: jwagner313 priority: normal severity: normal status: open title: ctypeslib patch for regular expression for symbols to include type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file40196/codegenerator.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24880 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24790] Idle: improve stack viewer
Changes by Mark Roseman m...@markroseman.com: -- nosy: +markroseman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24790 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24781] Improve UX of IDLE Highlighting configuration tab
Mark Roseman added the comment: Looking to get some feedback on a large chunk of new code (not yet complete), for the 'new' preferences dialog. Not so much UI things as if I've made any glaring structural errors which aren't obvious to this Python sorta-newbie. For lack of a better place, I've attached prefs-wip.patch, which just contains code for four entirely new files (querydialog.py, tkextras.py, uifactory.py, and uipreferences.py), no changes to existing files. You should be able to run it standalone just with e.g. python -m idlelib.uipreferences There's some comments at the start of uipreferences.py regarding structural changes from the code in the original configDialog.py. Thanks! -- keywords: +patch Added file: http://bugs.python.org/file40198/prefs-wip.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24781 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24383] consider implementing __await__ on concurrent.futures.Future
Changes by A. Jesse Jiryu Davis je...@emptysquare.net: -- nosy: +emptysquare ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24383 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Steve Dower added the comment: Why not [require administrative privileges]? Because some people want to use Python and don't have administrative permissions on their own machine (e.g. students, employees, researchers, etc.) The standard approach is to rebuild extension for every minor release, since the standard Python ABI is not guaranteed to stay backwards compatible. The last point I posted lets you rebuild extensions *with a different compiler*. So when you upgrade to VC15 you can use that to build your Python 3.5 extensions instead of VC14, and still ship those extensions to users without requiring them to install the VC15 redist. Static linking is part of this the fact that you have to reinstall Python and all extensions in case there's some bug in the CRT is really the main argument against doing static linking. The same argument applies against app-local copies of the runtime, which is why I'm trying to avoid these dependencies rather than volunteering to redistribute and update them for all extensions. Also, we already rebuild and release Python due to bugs in OpenSSL, so I see no reason why we wouldn't do the same for bugs in the (small) part of the CRT we statically link. Static linking of the CRT is normally only used in situations where you don't want to have single file executables without external dependencies, e.g. for working on arbitrary Windows systems without having to install anything. It's a valid use case, but not a general purpose one. Normally, yes, but we have a new use case now that the majority of the C runtime is preinstalled on machines and versionless. What's the advantage of using /MT when you then add all of the CRT libs to the set of libs which are dynamically linked ? The part that is statically linked is only a few functions that are either critical to program initialization or specially optimized by the compiler, and the rest of the CRT is versionless and managed by the operating system. To be clear, the DLLs I listed are not required by CPython or most pure-C extensions (including, I assume, cffi and Cython). It's only when you start using C++ and especially the Microsoft provided libraries for parallelism that you need these DLLs. If I want to ship a C extension compiled for Python 3.5 which links to an external DLL on the system, I will have to tell the users of the extension to first run VCredist in order for them to be able to use extension on their system, since Python 3.5 will not ship with the necessary CRT DLLs, correct ? Correct, just as it's always been. However, if you want to ship a C extension compiled for Python 3.5 which *does not* link to an external DLL, you *do not* have to tell your user to install anything. includes getting CRT bug fixes by means of OS updates rather than complete reinstalls of Python and all your extensions. Users of Python 3.5 will get CRT updates from the OS. Only a few trivial functions are statically linked under this scheme. Developers can work around these things, but if we end up requiring them to redistribute VCredist with every single package that has external dependencies, just to be able to install a binary package, because Python itself doesn't ship the necessary DLLs, then something is clearly broken for Python on Windows. Alternatively, we tell users to install VCredist by hand in case they plan to use Python with C extensions. Possible, but not very user friendly either. I proposed above making this an option in the installer. Problem is, it doesn't help extensions built with later compilers. Only the extension knows which version of the redist is needed. With Python 2.7 all this is not an issue, creating yet another road block to prevent upgrades :-( The issue with Python 2.7 is that you need to use VC9. If you think requiring everyone to use VC14 for Python 3.5 forever is less of an issue than having to recompile static libraries with a new version of the compiler, please say so explicitly, as I have not heard anyone claim that and need to hear it said in complete seriousness before I have any chance of believing it's true. chances are high that this will not actually work out in practice. Backwards compatibility is already hard, forward compatibility is really really difficult to achieve without a time machine. Agreed. However, the forward compatibility problem we're facing right now seems to be external libraries compiled under old compilers - that is, VC10 (to pick one example) failed at forward compatibility, and some work is required to fix that failure. If we concede defeat now, then we will also fail at forward compatibility, and it will take work in the future to correct our failure. I'm trying to do as much work now as I can to offset that work for everyone else later (and thanks for holding me accountable on this - it's more helpful than my apparently frustrated responses probably make it seem :) ). BTW: Do you
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Christoph Gohlke added the comment: The matplotlib extensions compiled with Python 3.5.0rc1 (/MT) are larger than those compiled with 3.5.0b4 (/MD). The C++ runtime is statically linked. This seems undesirable for the same reasons the UCRT is not linked statically. In Introducing the Universal CRT [1] James McNellis strongly recommend against static linking of the Visual C++ libraries, for both performance and serviceability reasons. In Visual Studio 2015 RTM Now Available [2] the same author commented that one may deploy the Universal CRT app-locally. Do these comments not apply to CPython? [1] http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx [2] http://blogs.msdn.com/b/vcblog/archive/2015/07/20/visual-studio-2015-rtm-now-available.aspx -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24879] Pydoc to list data descriptors in _fields order if it exists
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file40194/pydoc.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24879 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24879] Pydoc to list data descriptors in _fields order if it exists
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: - rhettinger stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24879 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
Christoph Gohlke added the comment: Another /MT only issue: cryptography-1.0 and other libraries depending on openssl fail to link to static MT openssl-1.0.1p: cryptlib.obj : error LNK2001: unresolved external symbol __iob_func This can be fixed manually [1]. [1] http://openssl.6102.n7.nabble.com/Compiling-OpenSSl-Project-with-Visual-Studio-2015-td59416.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24872 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24879] Pydoc to list data descriptors in _fields order if it exists
Raymond Hettinger added the comment: With the attached patch, the new output is: | -- | Data descriptors defined here: | | nickname | Alias for field number 0 | | firstname | Alias for field number 1 | | age | Alias for field number 2 | | __dict__ | A new OrderedDict mapping field names to their values -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24879 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24776] Improve Fonts/Tabs UX for IDLE
Raymond Hettinger added the comment: FWIW, I would also like a pair of hotkeys, Cmd + and Cmd - to increase and decrease the font (this would greatly improve usability for font size changes). There is good precedent for this in other editors and terminal programs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24776 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24870] Optimize coding with surrogateescape and surrogatepass error handlers
INADA Naoki added the comment: I've stripped Serhiy's patch for ascii. Here is benchmark result: https://gist.github.com/methane/2376ac5d20642c05a8b6#file-result-md Is there chance for applying this patch to 3.5.1? -- Added file: http://bugs.python.org/file40195/faster-decode-ascii-surrogateescape.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24870 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24764] cgi.FieldStorage can't parse multipart part headers with Content-Length and no filename in Content-Disposition
Pradeep added the comment: Hi Victor, I found similar problem at https://bugs.launchpad.net/barbican/+bug/1485452, is problem mentioned in the bug is same with mentioned bug? -- nosy: +pradeep ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24764 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24882] ThreadPoolExecutor doesn't reuse threads until #threads == max_workers
Changes by Matt Spitz mattsp...@gmail.com: -- title: ThreadPoolExceutor doesn't reuse threads until #threads == max_workers - ThreadPoolExecutor doesn't reuse threads until #threads == max_workers ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24882 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24882] ThreadPoolExecutor doesn't reuse threads until #threads == max_workers
Matt Spitz added the comment: On further investigation, it appears that we can't just check against the queue length, as it doesn't indicate whether threads are doing work or idle. A change here will need a counter/semaphore to keep track of the number of idle/working threads, which may have negative performance implications. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24882 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler
On 15.08.2015 22:41, Steve Dower wrote: Marc-Andre: there are a few concerns with including DLLs that aren't new with any of the 3.5 changes. * depending on another CRT version is fine *if* it is available (users may have to be told/helped to install the redistributable themselves) * CRT state will not be shared between versions. This is most obviously a problem if file descriptors are shared, but may also appear when writing console output, doing floating-point calculations, threading, and memory management. * potentially many more issues if C++ is used, but since Python doesn't use C++ this is mainly a concern where you have two DLLs using C++ and different runtimes (the CRT is partially/fully implemented in C++, so issues may theoretically occur with only one DLL using C++, but I'm yet to see any in practice or even identify any specific issues - maybe it's fine? I'm not going to guarantee it myself) These issues have always existed in the past, but were never a real problem, AFAIK, since the libraries intended to be used externally will typically come with e.g. memory management APIs to make sure they retain ownership of the allocated memory on their heap. It is quite natural to have to run VCredist as part of an application installer to make sure that the target system has the right VC runtime DLLs installed (and the installer will do the checking). The purpose of having DLLs for the runtime is to reduce overall size of the components as well as being able to easily address bugs and security issues in the runtime DLLs *without* having to recompile and redeploy all components using them. By forcing or even suggesting statically compiled Python C extensions, we would break this goal and potentially put our users at risk. IMO, we should follow the MS recommendations for Deployment in Visual C++ as we did in the past: https://msdn.microsoft.com/en-us/library/dd293574.aspx You can statically link a Visual C++ library to an application—that is, compile it into the application—so that you don't have to deploy the Visual C++ library files separately. However, we caution against this approach because statically linked libraries cannot be updated in place. If you use static linking and you want to update a linked library, you have to recompile and redeploy your application. Perhaps I'm missing something, but if the only advantage of statically compiling in the runtime is to have users not need to run VCredist at install time, it's not worth all the added trouble this introduces. If you are trying to make it possible to compile extensions with compilers following VC2015, then I also don't think this approach will work: the new compilers will use a new runtime and so issues you describe above come into play between the extensions and the interpreter. In that scenario, they will create real problems, as far as I understand, the since the Python C API expects to be able to e.g. share FDs, internal state such as which locale to assume, or use and free memory allocated by either the interpreter or the extension in the resp. other component (e.g. PyArg_ParseTuple()). So in the end, you'll still have to use the same compiler for extensions as the one used for compiling CPython to make sure you don't run into these issues - which is essentially the same situation as for Python =3.4. -- Marc-Andre Lemburg eGenix.com ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
