[issue23967] Make inspect.signature expression evaluation more powerful
Peter McCormick added the comment: This definitely works for the _socket.listen use case! In terms of generating such a signature using Argument Clinic, currently this is required: backlog: int(py_default=builtins.min(SOMAXCONN, 128), c_default=Py_MIN(SOMAXCONN, 128)) = 000 The attached patch lets Tools/clinic/clinic.py make an exception when both C and Python defaults are specified, simplifying the above to: backlog: int(py_default=builtins.min(SOMAXCONN, 128), c_default=Py_MIN(SOMAXCONN, 128)) -- keywords: +patch Added file: http://bugs.python.org/file39066/pdm-argument_clinic-mixed_py_and_c_defaults-v1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23967 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23967] Make inspect.signature expression evaluation more powerful
Peter McCormick added the comment: I missed the fact that Larry's patch obviates the need for the `builtins.` prefix, shortening the Argument Clinic parameter specification into: backlog: int(py_default=min(SOMAXCONN, 128), c_default=Py_MIN(SOMAXCONN, 128)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23967 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22848] Subparser help does not respect SUPPRESS argument
paul j3 added the comment: It'll take me a while to work through this proposed patch. My first reaction is that I am uncomfortable with adding an attribute to all parsers just to implement this help feature. For one thing it seems to cross functionality boundaries. I need to review how subparser help is implemented. A lot of the work is done in the subparsers action itself, not the HelpFormatter. I have a vague memory of another bug issue involving this subparser help. I'll have to look it up. There are several bug issues related to formatting `choices`. In some cases they are too long to display properly. And this formatting adds an iterablity requirement. I worked on consolidating choices formatting into a separate method. In one version it was module level function, in another refactoring I made it an Action method. If it was an Action method, then the subparsers_action class could implement its own version. Another thought - the formatting of choices is closely linked to the metavar. Anyways, at this point I have a bunch of random thoughts that need research and organizing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22848 ___ ___ 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
Terry J. Reedy added the comment:
Pending application of a patch, the following will work to only add args to
sys.argv when running from an Idle editor.
import sys
# ...
if __name__ == '__main__':
if 'idlelib.PyShell' in sys.modules:
sys.argv.extend(('a', '-2')) # add your argments here.
print(sys.argv) # in use, parse sys.argv after extending it
# ['C:\\Programs\\python34\\tem.py', 'a', '-2']
--
___
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
[issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files
Serhiy Storchaka added the comment: Thank you for your review Larry. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20175 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Changes by lilydjwg lilyd...@gmail.com: -- nosy: +lilydjwg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files
Roundup Robot added the comment: New changeset 2d8e4047c270 by Serhiy Storchaka in branch '3.4': Backported tests from issue #20175. https://hg.python.org/cpython/rev/2d8e4047c270 New changeset 867c509c8c5e by Serhiy Storchaka in branch '2.7': Backported tests from issue #20175. https://hg.python.org/cpython/rev/867c509c8c5e -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20175 ___ ___ 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 Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de: -- nosy: +wolma ___ 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
[issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files
Roundup Robot added the comment: New changeset 49007ed1a1a5 by Serhiy Storchaka in branch 'default': Issue #20175: Converted the _io module to Argument Clinic. https://hg.python.org/cpython/rev/49007ed1a1a5 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20175 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23972] Asyncio reuseport
New submission from Boris FELD: I'm trying to create some UDP sockets for doing multicast communication. I have the working code in synchronous way and try to port it to asyncio. One last issue is blocking for me, I'm on Mac OS X and for multicast UDP to work, the SO_REUSEPORT must be set on socket before bind. The problem is that I don't have access on socket, it's created inside asyncio method _create_connection_transport. I've seen that SO_REUSEADDR is already set (https://github.com/gvanrossum/tulip-try3/blob/7b2d8abfce1d7ef18ef516f9b1b7032172630375/asyncio/base_events.py#L720), so maybe we could also set SO_REUSEPORT only on platforms where it's available. `if hasattr(socket, 'SO_REUSEPORT')` should works. Or we could add an optional arguments with could be used to set some socket options, it could be more flexible that set SO_REUSEPORT. I could provide a patch for the best solution selected. -- components: asyncio messages: 241213 nosy: Boris.FELD, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: Asyncio reuseport type: behavior versions: Python 3.4, Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23972 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Marc-Andre Lemburg added the comment: We do some monkey-patching on MSVCCompiler as well, but mostly because distutils doesn't define a good way to subclass or configure a compiler class. IMO, monkey patching is a really bad idea. distutils should be evolved to provide more proper extension mechanisms like the ones via distclass and cmdclass. That said, we only use the compilers that Python itself is compiled with for each version, so your change should work for us (modulo some fixes we'd have to do to support it). One detail you are not considering with your patch is that distutils can well be used to build other tools and those may need older VC versions. Couldn't you at least keep the old compiler support around in a separate file ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: I'm not sure I like the way the simple idea Antoine has now resulted in a complete mess across platforms. None of this is documented anywhere except on this ticket. Since the change is a major one for anyone creating installers, packagers or otherwise dealing with compile extensions, I think we will need a PEP documenting the changes - and perhaps even have this discussed in retrospect on python-dev, possibly updating some of the changes already checked in. Reopening the issue until this is done and the PEP accepted. -- resolution: fixed - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Paul Moore added the comment: Sounds fair enough to me. I guess you have most of the bases covered, and AFAIK, we've never actually supported building extensions with anything other than the compiler python.org uses, so that seems a reasonable view to take. Apart from the numpy/scipy guys, the only other person I've ever heard of doing major distutils subclassing is Marc-André Lemburg. If you haven't spoken to him yet, it might be worth getting his view. I've added him to the nosy list. For my part, though, I'm happy with this change. -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Paul Moore added the comment: Hmm, I thought everyone was too scared to change distutils. Brave man :-) More seriously, I'm not sure I can comment usefully, I don't really understand any of this code, and the changes are pretty big. I guess the biggest risk is that someone directly references the changed code in a custom distutils command. Hmm, I just checked the numpy sources. It looks like numpy/distutils/command/config.py references msvc9compiler. And there's lots of references to msvccompiler. I'd suggest you confirm if numpy (and probably scipy) still build with these changes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20454] platform.linux_distribution() returns empty value on Archlinux and python 2.7
ha034 added the comment:
Hey guys,
Just add:
if os.path.exists('/etc/arch-release'):
distname = 'arch'
in _dist_try_harder
then replace the old list with this one:
_supported_dists = (
'SuSE', 'debian', 'fedora', 'redhat', 'centos',
'mandrake', 'mandriva', 'rocks', 'slackware', 'yellowdog', 'gentoo',
'UnitedLinux', 'turbolinux', 'arch')
And that's it, it works.
--
nosy: +ha034
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20454
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Steve Dower added the comment: Numpy uses a fork of distutils anyway, and currently nobody builds against 3.5 because of the compiler change. There are all sorts of monkey patches out there against this module and msvc9compiler (I've written some) and those should be unnecessary now, so I want then to break. I also don't see any reason for distutils to continue supporting old compilers, since 3.5 requires VC14, but maybe I'm wrong about that? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Steve Dower added the comment: Is there a way for those users to specify the version that they want? I can flow that through from somewhere, and honestly the compiler arguments have not changed in a long time. The problem is detecting an installation. I have formalized the DISTUTILS_USE_SDK variable, so setting up the env with that will be more reliable than previously. Also, I'm interested in what other patches you might apply. This is the last time I really want to touch this, so it's the time to get things like that added. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23972] Asyncio reuseport
Guido van Rossum added the comment: I think we left this unfinished. I think it would be best if we added a sock parameter (like for create_server()) but also added reuse_address and reuse_port parameters, treated similarly like the one on create_server(), and added a reuse_port parameter to create_server(). Or maybe there should only be one parameter that guides both; read http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t before you decide! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23972 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Changes by Christian Heimes li...@cheimes.de: -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9517] Make test.script_helper more comprehensive, and use it in the test suite
Michael McFadden added the comment: @Christie - Nope. This patch can stand on it's own, simply moving the package to where it belongs. In fact, I'd recommend applying the patch first. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9517 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files
Peter McCormick added the comment: The smallest of typo fixes. -- Added file: http://bugs.python.org/file39068/pdm-iofile_typo-v1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20175 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17831] urllib.URLopener.open breaks ActiveDirectory user
Changes by R. David Murray rdmur...@bitdance.com: -- resolution: - not a bug stage: - resolved status: open - closed type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17831 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21327] socket.type value changes after using settimeout()
Raúl Cumplido added the comment: Added new patch as per review comments. -- Added file: http://bugs.python.org/file39069/21327.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21327 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17831] urllib.URLopener.open breaks ActiveDirectory user
Howard Haimovitch added the comment: tested with David: two tests were made one using IE and the other using Firefox. Both were treated properly by the URL.lib library. Browsers do not preserve the backslash character. IE turns it into a forward slash and Firefox turns it into %5c. So urlliv is behaving correctly. -- nosy: +howardhaimovitch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17831 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21250] sqlite3 doesn't have unit tests for 'insert or [algorithm]' functionality.
Changes by Raúl Cumplido raulcumpl...@gmail.com: -- nosy: +raulcd ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21250 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: On 16.04.2015 18:12, Nick Coghlan wrote: I can tell you exactly where these files need to live side by side: index servers. We currently paper over it on PyPI for Windows and Mac OS X by leveraging the implicitly defined ABI compatibility of the CPython binary releases published on python.org, but that starts to break down as soon as people are using interpreter binaries built locally or by redistributors rather than by the CPython core development team. There's more to the computing world than Intel CPU architectures, and more kernel APIs than Linux, Darwin and Windows. But that's a completely different use case than what's being addressed in this ticket: This ticket is about C extension files, not packages or custom Python interpreter binary names. For packages, I agree, we would benefit from a more standardized ABI naming scheme that what setuptools or distutils currently have to offer. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18128] pygettext: non-standard timestamp format in POT-Creation-Date
R. David Murray added the comment: Thanks, Michael. -- resolution: - fixed stage: - resolved status: open - closed type: - behavior versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18128 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18128] pygettext: non-standard timestamp format in POT-Creation-Date
Roundup Robot added the comment: New changeset c969413584cf by R David Murray in branch 'default': #18128: use standard + timezone format in POT-Creation-Date header. https://hg.python.org/cpython/rev/c969413584cf -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18128 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Matthias Klose added the comment: Nick filed issue #23966 to document these changes. Yes, these tags should be documented, so that installers don't have to guess (currently they are only exposed in importlib.machinery.EXTENSION_SUFFIXES. What you describe as a simple idea is just another hack, only addressing the issue on x86 platforms, not addressing this for soft-float/hard-float calling conventions, not addressing this for endianness, not addressing this for other platform ABIs. And for all these cases there are machines where you can run the variants on the same machine. If you like to call this a mess, fine. But this is reality. I'm not creating this mess, I'm describing this and exposing it to the interpreter. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23966] More clearly expose/explain native and cross-build target information
Nick Coghlan added the comment: Capturing some additional notes regarding the purpose of multiarch platform triplets. These triplets should unambiguously capture: * syscall ABI (~= kernel) * instruction set (IA-32, IA-64, PowerPC, ARM, ARM64, etc) * endianness (big- or little- * word size (32- or 64-) The initial set of triplets from Debian covers GNU/Linux, GNU/Hurd and GNU/FreeBSD. Issue 23969 covers accurately capturing Mac OS X details, while issue 23670 covers iOS. (Issue 23496 should also likely take the issue 22980 changes into account for the Android cross-build) I've added Steve Dower to the nosy list as it would also be good to have a set of triplets defined for Windows. MAL suggested in issue 22980 that it may be worth capturing this ABI compatibility identification discussion as a PEP rather than solely as a set of issues with resulting changes to the documentation, which I think is a reasonable direction to go (even if it's done primarily as an after-the-fact communication of the build identification changes for inclusion in What's New, rather than a gating requirement for actually doing the work). -- nosy: +steve.dower ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20184] Derby #16: Convert 50 sites to Argument Clinic across 9 files
Serhiy Storchaka added the comment: The patch updated to the tip. -- Added file: http://bugs.python.org/file39070/dbm_clinic_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20184 ___ ___ 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
Serhiy Storchaka added the comment: The patch updated to the tip. -- Added file: http://bugs.python.org/file39071/codecs_clinic_2.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
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: On 16.04.2015 17:30, Matthias Klose wrote: Matthias Klose added the comment: Nick filed issue #23966 to document these changes. Yes, these tags should be documented, so that installers don't have to guess (currently they are only exposed in importlib.machinery.EXTENSION_SUFFIXES. What you describe as a simple idea is just another hack, only addressing the issue on x86 platforms, not addressing this for soft-float/hard-float calling conventions, not addressing this for endianness, not addressing this for other platform ABIs. And for all these cases there are machines where you can run the variants on the same machine. If you like to call this a mess, fine. But this is reality. I'm not creating this mess, I'm describing this and exposing it to the interpreter. The simple idea Antoine had was to be able to install C extensions compiled for different bit architectures, but the *same platform* into the same directory, which is similar to what we're doing for Python byte code files. The typical use case is to have a 32-bit version and a 64-bit version on the same system. It seems that the scope of this simple idea has now completely blown up in trying to stuff all kinds of other platform features into the binary names as well. And while doing so, we now have different naming styles on different platforms, require hand written configure files to support additional platforms, and have yet another system for associating platform information with binary Python files, in addition to PEP 3149, PEP 425 and PEP 427. See http://bugs.python.org/issue22980#msg232729 I don't think this is a good development and I can hardly imagine a use case where all those different ABIs will have to live on the same machine and in the same directory. At the same time you are creating incompatibilities which did not exist before, by requiring configure script fixes for unknown platforms. I'm -1 on these changes. I was +0 on Antoine's original idea, since that addresses real life use case you can run into every now and then. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Nick Coghlan added the comment: I can tell you exactly where these files need to live side by side: index servers. We currently paper over it on PyPI for Windows and Mac OS X by leveraging the implicitly defined ABI compatibility of the CPython binary releases published on python.org, but that starts to break down as soon as people are using interpreter binaries built locally or by redistributors rather than by the CPython core development team. There's more to the computing world than Intel CPU architectures, and more kernel APIs than Linux, Darwin and Windows. Fortunately, this platform ABI identification issue is not a new problem, but rather one where there's a rich history of existing expertise that we can draw from, rather than inventing our own custom solution that doesn't actually solve the problem properly. I agree it needs to be documented appropriately, perhaps including a PEP to explain *why* the changes are being made (rather than just documenting the end result), which is why I opened issue 23966. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files
Serhiy Storchaka added the comment: The patch updated to the tip. -- Added file: http://bugs.python.org/file39072/ssl_clinic_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20179 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Matthias Klose added the comment: On 04/16/2015 05:56 PM, Marc-Andre Lemburg wrote: Marc-Andre Lemburg added the comment: On 16.04.2015 17:30, Matthias Klose wrote: Matthias Klose added the comment: Nick filed issue #23966 to document these changes. Yes, these tags should be documented, so that installers don't have to guess (currently they are only exposed in importlib.machinery.EXTENSION_SUFFIXES. What you describe as a simple idea is just another hack, only addressing the issue on x86 platforms, not addressing this for soft-float/hard-float calling conventions, not addressing this for endianness, not addressing this for other platform ABIs. And for all these cases there are machines where you can run the variants on the same machine. If you like to call this a mess, fine. But this is reality. I'm not creating this mess, I'm describing this and exposing it to the interpreter. The simple idea Antoine had was to be able to install C extensions compiled for different bit architectures, but the *same platform* into the same directory, which is similar to what we're doing for Python byte code files. The typical use case is to have a 32-bit version and a 64-bit version on the same system. It seems that the scope of this simple idea has now completely blown up in trying to stuff all kinds of other platform features into the binary names as well. And while doing so, we now have different naming styles on different platforms, require hand written configure files to support additional platforms, and have yet another system for associating platform information with binary Python files, in addition to PEP 3149, PEP 425 and PEP 427. See http://bugs.python.org/issue22980#msg232729 I don't think this is a good development and I can hardly imagine a use case where all those different ABIs will have to live on the same machine and in the same directory. At the same time you are creating incompatibilities which did not exist before, by requiring configure script fixes for unknown platforms. I'm -1 on these changes. I was +0 on Antoine's original idea, since that addresses real life use case you can run into every now and then. I'm disappointed that you discredit any other use case besides what you think as the typical use case as not real life use case. Maybe you are focused on x86 only, but if you've been to PyCon 2014, you should have a nice Raspberry Pi. What do you run on it, a soft float, or a hard float distribution? How do you distribute extensions for that? Yes, you can run both at the same time. There are now the first 64bit Raspberry Pi like boards (https://www.96boards.org/). Most of the SoCs can run ARM32 hard- and soft-float binaries, but not all, and that's why AArch64 gets an ILP32 ABI too. Maybe you don't like the variety in the ARM world, but's that real life. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9517] Make test.script_helper more comprehensive, and use it in the test suite
Berker Peksag added the comment: Alternatively, you can import public functions from support/script_helper.py in support/__init__.py. Then you can do from test.support import assert_python_ok -- nosy: +berker.peksag stage: needs patch - patch review versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9517 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Handle bytes comparisons in difflib.Differ
Nick Coghlan added the comment: I think the convert to str - process as str - convert back to bytes approach is a good one - it's the same one we use in urllib.parse. In this case, since we explicit need to handle mixed encodings, I also agree with the idea of using surrogate escape to make it possible to tunnel arbitrary bytes through the process, and expose that as a new module level API for Python 3.5. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17445 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22708] httplib/http.client in method _tunnel used HTTP/1.0 CONNECT method
Vova added the comment: I don't know why I hardcoded version of HTTP, it was almost 6 months ago. Maybe because it just POC, or maybe because HTTP 1.0 is not allowed CONNECT method. Thank you for your patch and also for IDN support. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22708 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9517] Make test.script_helper more comprehensive, and use it in the test suite
Berker Peksag added the comment: Reviewing iss9517_move_script_helpers_py.patch: * Can you move script_helper.py by using hg mv? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9517 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22397] test_socket failure on AIX
Changes by David Watson bai...@users.sourceforge.net: -- nosy: +baikie ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22397 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16914] timestamping in smtplib.py to help troubleshoot server timeouts/delays
Maciej Szulik added the comment: After talking to David I'm submitting the patch once again with one slight change in ACKS file (I've put the names in the sorted order). -- Added file: http://bugs.python.org/file39073/issue16914.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16914 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9517] Make test.script_helper more comprehensive, and use it in the test suite
Christie added the comment: So @flipmcf we're sticking with the test.support.script_helper namespace? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9517 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16108] Include maintainer information in register/upload
Antti Haapala added the comment: I am the current maintainer of python-Levenshtein package on PyPI/Github, but I wrote about 0 % of the functionality; almost everything excepting bug fixes and Python 3 compatibility was written by the original author David Necas and possibly contributors; now I am contacted as the author of the package, a.k.a why did you code it this way - I do not know. Currently PyPI does seem to have a field for both maintainer and author if I enter PKG-INFO data manually; these both would also be available on the page and JSON metadata etc. I'd really want to be able to generate the correct PKG-INFO automatically from the setup() arguments. -- nosy: +ztane ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16108 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: On 16.04.2015 18:53, Matthias Klose wrote: I'm disappointed that you discredit any other use case besides what you think as the typical use case as not real life use case. Maybe you are focused on x86 only, but if you've been to PyCon 2014, you should have a nice Raspberry Pi. What do you run on it, a soft float, or a hard float distribution? How do you distribute extensions for that? Yes, you can run both at the same time. There are now the first 64bit Raspberry Pi like boards (https://www.96boards.org/). Most of the SoCs can run ARM32 hard- and soft-float binaries, but not all, and that's why AArch64 gets an ILP32 ABI too. Maybe you don't like the variety in the ARM world, but's that real life. I'm not trying to discredit any use cases, I just don't see them. For package distributions you do need to make your distribution files unique and it makes sense adding such complex ABI tags to them, including even having to invest into manually maintaining them. However, for plain .so files that you have on your system (which will mostly like not support more than 2-4 different architecture configurations running at the same time), I don't currently see a need to make things more complicated than necessary. Perhaps you can point me to some use cases where the triple platform tag is really useful. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20669] OpenBSD: socket.recvmsg tests fail with OSError: [Errno 40] Message too long
David Watson added the comment: Sending multiple control messages at once isn't Linux-specific - the tests in question passed on FreeBSD. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20669 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Marc-Andre Lemburg added the comment: On 16.04.2015 15:18, Steve Dower wrote: Is there a way for those users to specify the version that they want? Indirectly, yes. There's the build_ext --compiler argument which then interfaces to ccompiler.new_compiler. In essence, you can specify the compiler type. The compiler is then looked up in the ccompiler.compiler_class registry. Adding new compiler classes is possible through monkey patching (since the modules implementing them must be in the distutils package). Not a nice design... exposing a proper registry API for the compiler classes would be better, even if it's just via something like a compilerclass dictionary in the setup() call. On Unix, it is possible to specify the compiler using the CC env var. I can flow that through from somewhere, and honestly the compiler arguments have not changed in a long time. The problem is detecting an installation. We completely gave up on the automatic detection of the installation and only rely on the vcvars style batch files to set up things correctly for each MS compiler version and then have distutils find it. I have formalized the DISTUTILS_USE_SDK variable, so setting up the env with that will be more reliable than previously. Also, I'm interested in what other patches you might apply. This is the last time I really want to touch this, so it's the time to get things like that added. Something we've needed is a standard way to extract the lib and include paths used by the compiler: def get_msvc_paths(): Return a tuple (libpath, inclpath) defining the search paths for library files and include files that the MS VC++ compiler uses per default. Both entries are lists of directories. Only available on Windows platforms with installed compiler. and the only monkey-patching we do is to be able to modify the default compiler switches used: if python_version '2.4': # VC6 MSVC_COMPILER_FLAGS = ['/O2', '/Gf', '/GB', '/GD', '/Ob2'] elif python_version '2.6': # VC7.1 MSVC_COMPILER_FLAGS = ['/O2', '/GF', '/GB', '/Ob2'] else: # VC9 MSVC_COMPILER_FLAGS = ['/O2', '/GF', '/Ob2'] if hasattr(MSVCCompiler, 'initialize'): # distutils 2.5.0 separates the initialization of the # .compile_options out into a new method .initialize() # remember old _initialize old_MSVCCompiler_initialize = MSVCCompiler.initialize def mx_msvccompiler_initialize(self, *args, **kws): apply(old_MSVCCompiler_initialize, (self,) + args, kws) # Add our extra options self.compile_options.extend(MSVC_COMPILER_FLAGS) # Install new initialize MSVCCompiler.initialize = mx_msvccompiler_initialize Would be great to a standard way to do this in the MSVCCompiler class or associated module. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Joel Taddei added the comment: I took a stab at the calendar module. Found a few items in the documentation which weren't listed in the above list: LocaleTextCalendar, LocaleHTMLCalendar, and weekheader. I was curious though about week and prweek as month and prmonth are documented and exported should we add week and prweek to the export docs? -- Added file: http://bugs.python.org/file39067/Issue23883_calendar_all.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23883 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files
Changes by Peter McCormick pe...@pdmccormick.com: -- nosy: +pdmccormick ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20175 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16108] Include maintainer information in register/upload
Éric Araujo added the comment: Again, if PyPI can display both pieces of information, then it will be okay to send both. The change should not break third-party indexes like devpi-server. Is there a PyPI ticket for this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16108 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Donald Stufft added the comment: Perhaps you can point me to some use cases where the triple platform tag is really useful. If I understand correctly (and ABI isn't my strong suite), it would be useful in the sense that you could utilize it to create a sort of fat wheel that included the .so's for multiple architectures and then pip could simply drop them all into place and have the interpreter decide which one to load. This is useful because maybe you have one .so in a wheel and 30 .py files, it's somewhat wasteful (both disk space and in cache efficiency) to have 10 different wheel files and those 30 .py files duplicated when it could be possible to have a single one serving 10 different architectures. To be clear, this ability doesn't yet exist in Wheel and I don't know of anyone pushing for it, but if Python is smart enough to load the right .so that makes fat wheels significantly easier to implement (in fact, you wouldn't need to add anything else to pip or the wheel spec to handle it I think). -- nosy: +dstufft ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Ned Deily added the comment: Antoine's ticket is the first in two decades to request being able to install .so extension files side-by-side, so even if times and platforms change, people don't seem to have a big issues without this feature. That's exactly what PEP 3149 was supposed to implement, isn't it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: On 16.04.2015 19:44, Donald Stufft wrote: Donald Stufft added the comment: Perhaps you can point me to some use cases where the triple platform tag is really useful. If I understand correctly (and ABI isn't my strong suite), it would be useful in the sense that you could utilize it to create a sort of fat wheel that included the .so's for multiple architectures and then pip could simply drop them all into place and have the interpreter decide which one to load. This is useful because maybe you have one .so in a wheel and 30 .py files, it's somewhat wasteful (both disk space and in cache efficiency) to have 10 different wheel files and those 30 .py files duplicated when it could be possible to have a single one serving 10 different architectures. Well, it's even more wasteful if you have to download 100MB wheels with all the different platforms when the dedicated wheel would just need 1.5MB. This approach has been considered a few times in distutils history and no one really liked it because it would increase the download requirements for the users a lot. It does make things easier for the packages, though, but then again, this can also be had by having different subdirs in the wheel or other package format to address the issue of having name collisions. Today, you usually have a web installer take care of grabbing only the bits you need. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23828] test_socket testCmsgTruncLen0 gets received malformed or improperly-truncated ancillary data warning under OS X
David Watson added the comment: In this test (and nearby ones), the receiver provides too little space to receive the file descriptors that are sent, so that the control message has to be truncated if it is to be received at all. The warning may indicate that the cmsghdr struct received still claims that the message contains the full amount of data (so that socket.recvmsg() would overrun the buffer if it actually believed the cmsghdr). With that in mind, you might want to check whether file descriptors that don't fit are still received (say the sender sends three file descriptors when the receiver only asks for two, and the receiver gets a control message saying it now has descriptors on numbers 3 and 4, but it also gets a file descriptor on number 5 which it isn't told about). If they are, it's a kernel bug which could be used for denial of service by exhausting the receiving process' quota of file descriptors (and the warning would probably go away if it were fixed). -- nosy: +baikie ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23828 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Changes by Mark Lawrence breamore...@yahoo.co.uk: -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16108] Include maintainer information in register/upload
Donald Stufft added the comment: PyPI should already handle it fine, and Warehouse certainly does. -- nosy: +dstufft ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16108 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: On 16.04.2015 19:14, Marc-Andre Lemburg wrote: However, for plain .so files that you have on your system (which will mostly like not support more than 2-4 different architecture configurations running at the same time), I don't currently see a need to make things more complicated than necessary. Perhaps you can point me to some use cases where the triple platform tag is really useful. Antoine's ticket is the first in two decades to request being able to install .so extension files side-by-side, so even if times and platforms change, people don't seem to have a big issues without this feature. If you have a need, it's not really hard to build your extensions for different architecture ABIs in different directories. We've been doing this for years, just like everyone else. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: On 16.04.2015 19:47, Ned Deily wrote: Ned Deily added the comment: Antoine's ticket is the first in two decades to request being able to install .so extension files side-by-side, so even if times and platforms change, people don't seem to have a big issues without this feature. That's exactly what PEP 3149 was supposed to implement, isn't it? No, PEP 3149 is about the Python ABI, following PEP 3147, which implements this for PYC files. The intent is to be able to have mutliple *Python* ABI/API versions installed side-by-side, not multiple platform ABI versions :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23974] random.randrange() biased output
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +mark.dickinson, rhettinger, serhiy.storchaka stage: - needs patch type: - security ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23974 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16914] timestamping in smtplib.py to help troubleshoot server timeouts/delays
R. David Murray added the comment: Review comments added. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16914 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7159] Urllib2 authentication memory.
Roundup Robot added the comment: New changeset 1b9e81cb83bc by R David Murray in branch 'default': #7159: generalize urllib prior auth support. https://hg.python.org/cpython/rev/1b9e81cb83bc -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5497] openssl compileerror with original source
Changes by Ned Deily n...@acm.org: -- nosy: +steve.dower, zach.ware ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5497 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22829] Add --prompt option to venv
Stéphane Wirtel added the comment: Based on the patch of Łukasz, I have updated it to the last revision of Python 3.5a3 (today, 16th April) stephane@sg1 ~/p/c/bin ./python3.5 --version Python 3.5.0a3+ stephane@sg1 ~/p/c/bin ./python3.5 Python 3.5.0a3+ (default:c969413584cf+, Apr 16 2015, 15:17:46) I tested the patch, this one works fine and the prompt is really changed if we specify it on the command line of -m venv -- nosy: +matrixise Added file: http://bugs.python.org/file39076/venv-prompt-argument-3_5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22829 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23975] numbers.Rational implements __float__ incorrectly
New submission from Wolfgang Maier: numbers.Rational defines __float__ like this: def __float__(self): float(self) = self.numerator / self.denominator It's important that this conversion use the integer's true division rather than casting one side to float before dividing so that ratios of huge integers convert without overflowing. return self.numerator / self.denominator This assumes that division of two Integral numbers returns a float, which the numbers ABC does not enforce in any way. IMO, the only logical assumption is that division of any two Integral or Rational numbers gives a Real, for which the ABC guarantees a __float__ method in turn. So I think Rational.__float__ should return float(self.numerator / self.denominator) -- components: Library (Lib) messages: 241270 nosy: wolma priority: normal severity: normal status: open title: numbers.Rational implements __float__ incorrectly type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23975 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] Add urllib2.HTTPBasicPriorAuthHandler for use with APIs that don't return 401 errors
Roundup Robot added the comment: New changeset 1b9e81cb83bc by R David Murray in branch 'default': #7159: generalize urllib prior auth support. https://hg.python.org/cpython/rev/1b9e81cb83bc -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23976] ZipFile.writestr implies non-regular files
New submission from D. Alphus: When ZipFile.writestr is called with arcname as its first parameter, it creates a ZipInfo object that has 0o0600 16 as its external_attr. Files created with write generally have 0o0100600 (S_IFREG is set indicating a regular file). Some archive managers (like Ark) will not populate the extracted file unless it contains this flag. -- components: Library (Lib) messages: 241274 nosy: dalphus priority: normal severity: normal status: open title: ZipFile.writestr implies non-regular files type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23976 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20454] platform.linux_distribution() returns empty value on Archlinux and python 2.7
R. David Murray added the comment: Since the direction we are heading seems to toward deprecating linux_distribution (see http://bugs.python.org/issue1322#msg207427), I think this issue should be closed. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20454 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7159] Urllib2 authentication memory.
R. David Murray added the comment: Here is the doc patch for the design that Akshit and I agreed to after re-consideration of the API. This eliminates the HTTPBasicPriorAuthHandler in favor of the HTTPPasswdMgrWithPriorAuth password manager and putting support for prior auth on the AbstractBasicAuthHandler based on whether or not the password_mgr supports the is_authenticated and updated_authenticated methods. This redesign means that the Proxy handler automatically gets support for prior auth. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23903] Generate PC/python3.def by scraping headers
Martin v. Löwis added the comment: I think the approach taken in this script is incorrect. It leads to false modifications of the stable ABI, making it in fact unstable. Four examples: PyAST_FromNode does not belong to the stable ABI, because struct _node doesn't belong to the stable ABI (see PEP 384 for a list of structures that belong to the stable ABI). In fact, ast.h isn't even a header file that extension modules should regularly include. All deletions are (e.g. PyCFunction_New) are certainly incorrect: functions must never be removed from the stable ABI. In fact, Objects/methodobject.c preserves PyCFunction_New just for the sake of the stable ABI (despite there being no longer a declaration in the header file). PyErr_SetFromWindowsErrWithFilename could belong to the stable ABI, or not, depending on the intention of stability in its addition. Since it was there since 3.0, and had not been in the stable ABI back then, I'd claim that it doesn't belong to the stable ABI (apparently, nobody has missed it). OTOH PyExc_BrokenPipeError might be a useful addition to the stable ABI. However, it was not there in 3.0, so the header files ought to version-guard its declaration, but currently don't. So I prefer if the def file keeps being maintained manually; I don't mind if there is a tool that checks for inconsistencies, leaving their resolution to a maintainer. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23903 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5497] openssl compileerror with original source
Stéphane Wirtel added the comment: what's the status of this issue? about SSL and Python on Windows for the builder script. -- nosy: +matrixise ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5497 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20769] Reload() description is unclear
Brett Cannon added the comment: Patch LGTM. -- stage: - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20769 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16914] timestamping in smtplib.py to help troubleshoot server timeouts/delays
Roundup Robot added the comment: New changeset 65037930edb0 by R David Murray in branch 'default': #16914: add timestamps to smtplib debugging output via new debuglevel 2. https://hg.python.org/cpython/rev/65037930edb0 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16914 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16914] timestamping in smtplib.py to help troubleshoot server timeouts/delays
Roundup Robot added the comment: New changeset de19c0ffe8d5 by R David Murray in branch 'default': News item for #16914. https://hg.python.org/cpython/rev/de19c0ffe8d5 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16914 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7159] Urllib2 authentication memory.
Akshit Khurana added the comment: Updated code as per docs -- Added file: http://bugs.python.org/file39075/auth11.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7159] Urllib2 authentication memory.
R. David Murray added the comment: Actually attaching the patch this time. -- Added file: http://bugs.python.org/file39074/prior_auth_docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16914] timestamping in smtplib.py to help troubleshoot server timeouts/delays
Maciej Szulik added the comment: Review comments addressed in latest patch. -- Added file: http://bugs.python.org/file39077/issue16914.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16914 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: On 16.04.2015 20:17, Donald Stufft wrote: Donald Stufft added the comment: Well, it's even more wasteful if you have to download 100MB wheels with all the different platforms when the dedicated wheel would just need 1.5MB. I think it's going to vary greatly based on how many platforms you're attempting to support and how big your .so's are compared to the rest of the Wheel. You can also mix and match, do a single bundle for the most popular platforms (which will mean that you're almost always serving out of cache) but then do individual wheels for the less popular platforms to keep the file size of the main wheel from bloating up with a bunch of .so's for platforms which are unlikely to be needed very often. Whatever you do, you're still going to force all your main users to download things they don't need, so I don't see the argument of optimizing downloads or caches. Another possible (future) benefit - Right now we have executable zip files, but they can only reasonably contain pure Python files. There are rumblings of making it so it's possible to import .so's from inside of an executable zip file. If you bake in the platform ABI into the .so file name, it would mean in that possible future you could have a single executable zip file that just works across multiple platforms as long as you already have Python installed. Since you need special support for such ZIP files (either using dlopen hacks or temporarily extracting them), you might as well deal with the platform dependencies in that handler. No need to force the platform tags on all your .so file for no apparent reason. There's a very real use case for having multiple Python versions installed which was the motivation for the PEPs I quoted, but this development is one of those YAGNI features only very few people will ever need. I do agree that pretty much every place someone would want to do this, could possibly be implemented by having it look inside a per platform directory (you could implement fat wheels for instance by having platform sub dirs, same with a single executable zip file), however doing that causes duplication because every place you deal with .so's then need to deal with the question of platform ABI and have to come up with their own solution to it, instead of having a central solution which is managed by Python itself and can be re-used by all of these situations. I'm not saying that having a central solution is wrong. All I'm saying is that the implementations on this ticket are not within the scope of the ticket and instead need a proper PEP to see where the real use cases are and whether this particular way of doing things is a way we all want to go. We now have four ways of describing ABI flags in Python (well, actually even more, since Linux, Windows and OX S use different approaches for the platform ABI .so flags). This can't possibly be a good approach. I can already see all the different OS vendors creating their own little platform triplet extensions. In the end, it's rather likely that an extension compiled with eg. openSUSE won't run on Fedora or Debian anymore and vice-versa; and one compiled with vanilla Python probably won't run on Apples' Python anymore for similar reasons. Not a good perspective. This is going to make distributing binaries harder, not easier. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23974] random.randrange() biased output
New submission from Christopher Gurnee: Due to an optimization in random.randrange() only in Python 2, as the stop-start range approaches 2^53 the output becomes noticeably biased. This bug also affects random.SystemRandom. For example, counting the number of even ints in a set of 10^6 random ints each in the range [0, 2^52 * 2/3) produces normal results; about half are even: sum(randrange(2**52 * 2//3) % 2 for i in xrange(100)) / 100.0 0.499932 Change the range to [0, 2^53 * 2/3), and you get a degenerate case where evens are two times more likely to occur than odds: sum(randrange(2**53 * 2//3) % 2 for i in xrange(100)) / 100.0 0.39 The issue occurs in three places inside randrange(), here's one: if istart = _maxwidth: return self._randbelow(istart) return _int(self.random() * istart) _maxwidth is the max size of a double where every digit to the left of the decimal point can still be represented w/o loss of precision (2^53, where a double has 53 mantissa bits). With istart = _maxwidth, _randbelow() behaves correctly. With istart _maxwidth, the rounding error in random() * istart begins to cause problems as istart approaches 2^53. Changing _maxwidth to be significantly less should (practically speaking anyways) fix this, although I'm open to suggestion on just how conservatively it should be set. -- components: Library (Lib) messages: 241261 nosy: gurnec priority: normal severity: normal status: open title: random.randrange() biased output versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23974 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16914] timestamping in smtplib.py to help troubleshoot server timeouts/delays
R. David Murray added the comment: Thanks Gavin and Maciej. I can tell it is the end of the sprints...my brain is fuzzy and I forgot both the news item and missed the missing versionchanged when I reviewed -- resolution: - fixed stage: patch review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16914 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23974] random.randrange() biased output
Skip Montanaro added the comment: I'm completely unqualified to offer a concrete, expert opinion here, but it seems like defaulting _maxwidth to 1L52 should work. I have no idea of the resulting performance implications though. for bpf in (45, 46, 47, 48, 49, 50, 51, 52, 53): ... print bpf, ... print sum(randrange(2**53 * 2//3, _maxwidth=1Lbpf) % 2 for i in xrange(100)) / 100.0, ... print sum(randrange(2**52 * 2//3, _maxwidth=1Lbpf) % 2 for i in xrange(100)) / 100.0 ... 45 0.499959 0.500144 46 0.501622 0.500371 47 0.500257 0.499692 48 0.499567 0.499942 49 0.499789 0.50028 50 0.499882 0.500488 51 0.500479 0.50006 52 0.500553 0.500234 53 0.33275 0.500296 -- nosy: +skip.montanaro ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23974 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23974] random.randrange() biased output
Christopher Gurnee added the comment: I shouldn't have called this a rounding error issue, that's not really what it is. A smaller example might help. If I'm given a random int, x, in the range [0, 12), and asked to produce from it a random int, y, in the range (0,8], I've got (at least?) two choices: 1. y = x If x 8 Else fail 2. y = f(x), where f maps values from [0, 12) - (0,8] The problem with method 2 is you end up with a mapping like this: 0,1 - 0 2- 1 3,4 - 2 5- 3 6,7 - 4 8- 5 9,10 - 6 11 - 7 _randbelow() uses method 1 above. _int(self.random() * istart) is more like method 2. I chose 2^53 * 2/3 just because the bias was easy to demonstrate. There will always be some bias when stop-start % 2^53 != 0, but it might not manifest itself as easily as checking for evenness. Personally, I think 2^52 is still way too high as a cutoff point for using the (presumably faster, I didn't timeit) method 2, but I don't claim to be an expert here -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23974 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] Add urllib2.HTTPBasicPriorAuthHandler for use with APIs that don't return 401 errors
R. David Murray added the comment: The commit just made re-engineers the new API to generalize it. Now we can fully support the MAY preemptively send part of the rfc, even when doing the normal 401 dance for the first request. This is accomplished through a new password manager instead of a new Handler, and by adding support in the AbstractBasicAuthHandler for detecting if the passed in password manager supports authentication tracking and using it if it does. This means that the proxy handler can also now do prior auth. If anyone on this issue thinks we screwed this up, please let me know :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16914] timestamping in smtplib.py to help troubleshoot server timeouts/delays
Roundup Robot added the comment: New changeset 724473a18ada by R David Murray in branch 'default': #16914: reflow paragraph and add missing versionchanged. https://hg.python.org/cpython/rev/724473a18ada -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16914 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus
R. David Murray added the comment: Martin, if you think the patch is complete and ready to commit, please change the stage to commit review. I'm trying to encourage core devs to look at the patches in commit review state and commit them :) -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13866 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23970] Update distutils.msvccompiler for VC14
Steve Dower added the comment: So it looks like what I should do is use the include_dirs and library_dirs members from CCompiler so they can be set through other properties. The extra arguments are passed into compile() as extra_preargs and extra_postargs, though I'm not entirely sure where they come from. I'd rather figure out how to use those than invent a new way of specifying them (FWIW, they've always been supported by the various msvccompiler implementations). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23970 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Changes by Brett Cannon br...@python.org: -- nosy: -brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23903] Generate PC/python3.def by scraping headers
Steve Dower added the comment: That would be the preferred way to do it, but we got no traction from anyone at PyCon or on python-dev when we tried to get people to look at what's changed. I suspect we haven't marketed the stable API well enough to have a lot of users, and the build tools still mark everything as 3.x-specific rather than 3-specific. Keeping it as a bare minimum interface has its value, but it's not unreasonable to expect that the functions available from the headers under Py_LIMITED_API are actually exported by python3.dll. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23903 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19494] Add urllib2.HTTPBasicPriorAuthHandler for use with APIs that don't return 401 errors
Changes by Akshit Khurana axitkhur...@gmail.com: -- nosy: +axitkhurana ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19494 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: On 16.04.2015 20:21, Ned Deily wrote: Ned Deily added the comment: No, PEP 3149 is about the Python ABI, following PEP 3147, which implements this for PYC files. The intent is to be able to have mutliple *Python* ABI/API versions installed side-by-side, not multiple platform ABI versions :-) Well, for all practical purposes, the platform *is* part of the ABI :=) Yes, but if all your files on your box share the same ABI, do you really want to have all of them come with an extra name extension ? I mean: If all your apples are green, would you write green on them to remember ? ;-) All Linux distributions I know place the 32-bit and 64-bit versions of shared libs into different directories rather than putting them all into a single dir and adding ABI flags to the .so files. Windows does this too. FreeBSD as well. Why should Python behave differently ? Just because we can is not really a good answer, IMO. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22980] C extension naming doesn't take bitness into account
Marc-Andre Lemburg added the comment: On 17.04.2015 00:51, Donald Stufft wrote: Since you need special support for such ZIP files (either using dlopen hacks or temporarily extracting them), you might as well deal with the platform dependencies in that handler. No need to force the platform tags on all your .so file for no apparent reason. There are other reasons as have already been mentioned, this is just yet another reason (and on it's own I'd agree it's not a sufficiently compelling use case), but when I see a pattern of things which all need the same thing then that speaks to me that it should live someplace centrally instead of having each one reimplement it. Sure, but whatever the central implementation is going to be, it doesn't necessarily have to require sticking platform ABI flags on all .so files, even those which will never need to be installed side-by-side. The more paths you need to stat when searching a shared mod, the slower Python will get. There's a very simple trick which some packages used in the past for sumo distributions - you simply modify the __path__ attribute of the package to point to the platform dependent files in the __init__.py file and Python will then automagically use the right C extensions. To simplify this, the platform triplets and other platform ABI flags could be made available via the sys or sysconfig module for importers and other tools to pick up. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Handle bytes comparisons in difflib.Differ
Greg Ward added the comment: Just uploaded https://bugs.python.org/file39083/fa4c6160c518.diff. Pretty sure I've addressed all of @berker.peksag's review comments: thanks for that! I also fixed a number of subtle bugs in the tests. Pro tip: when asserting that something raises TypeError, inspect the exception message. There are many many ways that Python code can raise TypeError *other than* the condition you thought you were testing for. ;-) I'm happy with this patch now unless anyone else spots problems. @durin42: have you been trying this patch with your Mercurial-on-Python-3.5 patches? This would be a good time to re-update your difflib.py. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17445 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17445] Handle bytes comparisons in difflib.Differ
Berker Peksag added the comment: Thanks, looks great. Two trivial comments about the documentation: * Needs ``.. versionadded:: 3.5`` * *dfunc(a, b, fromfile, tofile, fromfiledate, tofiledate, n, lineterm)* - ``dfunc(a, b, fromfile, tofile, fromfiledate, tofiledate, n, lineterm)`` -- versions: -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17445 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18262] ZipInfo.external_attr are not documented
Alex Lord added the comment: Any follow up on this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18262 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18262] ZipInfo.external_attr are not documented
Changes by Ned Deily n...@acm.org: -- nosy: +alanmcintyre, serhiy.storchaka, twouters ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18262 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23964] Update README documentation for IDLE tests.
Terry J. Reedy added the comment: Although the text is aimed at people writing tests, I agree with starting with a new short section 0. Running all Idle tests. The sentence already there is specific to automated unittests. There is also a separate human-mediated test system run with python -m idlelib.idle_test.htest (more below). This command should be added in this section. Retesting, python -m test.test_idle on the command line no longer works for me on installed 3.4.3, Win7. Instead I get c:\Programs\Python34\python.exe: Error while finding spec for 'test.test_idle' (class 'AttributeError': 'module' object has no attribute '__path__') Did you get this or is does my install have a problem? Running test_idle.py from the Idle editor works fine. python -m test -v test_idle fails with no output. Onward: I do not want to indent code because I want people, including myself, to be able to cut and paste. Some of the other edits look good at first glance. I may have questions on some. Something needs to be added to README about human-mediated tests, beyond the bottom-line summary in section 0. There is a page long docstring in htest.py. I am not sure how much to move to or duplicate in README (after further editing). Any opinion, as a naive reader? -- assignee: - terry.reedy nosy: +terry.reedy stage: - patch review versions: +Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23984] Documentation error: Descriptors
New submission from bjonnh: in https://docs.python.org/3.5/howto/descriptor.html#static-methods-and-class-methods (same problem in all python 3.x documentations) There is this example where the return of f function is printed and there is already a print in the function: class E(object): def f(x): print(x) f = staticmethod(f) print(E.f(3)) 3 print(E().f(3)) 3 It should probably be: def f(x): return(x) or E.f(3) 3 E().f(3) -- assignee: docs@python components: Documentation messages: 241312 nosy: bjonnh, docs@python priority: normal severity: normal status: open title: Documentation error: Descriptors type: enhancement versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23980] Documentation for format units starting with 'e' is inconsistent
Larry Hastings added the comment: One more idea. We annotate with an when you pass in a pointer to a variable. So format unit 'i' would get [ int], 's' would get [ char *], and 'es#' would get [char *, char *, int]. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23984] Documentation error: Descriptors
Changes by Ned Deily n...@acm.org: -- nosy: +rhettinger versions: +Python 2.7 -Python 3.2, Python 3.3, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23984 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18262] ZipInfo.external_attr are not documented
Changes by Ned Deily n...@acm.org: -- stage: needs patch - patch review versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18262 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22269] Resolve distutils option conflicts with priorities
Changes by Piotr Dobrogost p...@bugs.python.dobrogost.net: -- nosy: +piotr.dobrogost ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22269 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
