[Python-Dev] Making PyInterpreterState an opaque type

Hi all, I've been working on the runtime lately, particularly focused on my multi-core Python project. One thing that would help simplify changes in this area is if PyInterpreterState were defined in Include/internal. This would mean the type would be opaque unless Py_BUILD_CORE were defined. T

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Thu, Feb 14, 2019 at 9:29 AM Barry Warsaw wrote: > On Feb 13, 2019, at 23:08, Matěj Cepl wrote: > > > Is this relevant to the discussion at hand? We are talking about > > the binary /usr/bin/python3 which will be surely be provided > > even by Python 4, won't it? > > Why would it be? Since t

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Fri, Feb 15, 2019 at 2:39 PM Brett Cannon wrote: > In my experience after using 'py' on Windows I consistently miss it on > UNIX now, so to me there is enough of a benefit that I will continue to > chip away at the project until it's done regardless of whether anyone else > uses it. :) > And

Re: [Python-Dev] datetime.timedelta total_microseconds

Indeed there is a potential loss of precision: _timedelta_to_microseconds(timedelta(0, 1, 1)) returns 100 where conversion function is defined according to the initial message in this thread On Fri, Feb 15, 2019 at 2:29 PM Paul Ganssle wrote: > I'm still with Alexander on this. I see funct

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Thu, Feb 14, 2019 at 10:21 AM Gustavo Carneiro wrote: > > > On Thu, 14 Feb 2019 at 15:52, Victor Stinner wrote: > >> Le jeu. 14 févr. 2019 à 14:38, Matthias Klose a écrit : >> > Debian's concern about pointing python to python3 is that it will break >> software >> > after an upgrade. The cu

Re: [Python-Dev] datetime.timedelta total_microseconds

I'm still with Alexander on this. I see functions like total_X as basically putting one of the arguments directly in the function name - it should be `total_duration(units)`, not `total_units()`, because all of those functions do the same thing and only differ in the units they use. But Alexander'

Re: [Python-Dev] Is distutils.util.get_platform() the "current" or the "target" platform

On Fri, Feb 15, 2019 at 2:02 PM Steve Dower wrote: > On 14Feb2019 1147, Gregory P. Smith wrote: > > To alleviate confusion long term I'd love it if we could deprecate the > > unqualified get_platform() API and point people towards always being > > explicit about get_target_platform() vs get_curre

Re: [Python-Dev] Is distutils.util.get_platform() the "current" or the "target" platform

On 14Feb2019 1147, Gregory P. Smith wrote: To alleviate confusion long term I'd love it if we could deprecate the unqualified get_platform() API and point people towards always being explicit about get_target_platform() vs get_current_platform(). This is an option too, though it doesn't reduce

Re: [Python-Dev] datetime.timedelta total_microseconds

On Fri, Feb 15, 2019 at 11:58 AM Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > A function with "microseconds" in the name IMO misleadingly suggests that > it has something closer to microsecond accuracy than a 1-second granularity. > it sure does, but `delta.total_seconds()` is a fl

Re: [Python-Dev] datetime.timedelta total_microseconds

A function with "microseconds" in the name IMO misleadingly suggests that it has something closer to microsecond accuracy than a 1-second granularity. Rob Cliffe On 14/02/2019 05:05:54, Richard Belleville via Python-Dev wrote: In a recent code review, the following snippet was called out as re

Re: [Python-Dev] Adding test.support.safe_rmpath()

On Fri, Feb 15, 2019 at 11:44 AM Steve Dower wrote: > That said, I'd love to have a context manager that we can use to make > this easier. Really, none of us should be having to decide "how am I > going to use a temporary location on the file system in my test", > because we should have one obviou

[Python-Dev] OpenSSL 1.1.1 fixes merged into Python 2.7

Hi, I reviewed and merged pull requests written by my colleague Charalampos Stratakis to backport OpenSSL 1.1.1 fixes into the future Python 2.7.16. Benjamin Peterson (Python 2.7 release manager) wrote me: "I would very much like to see 1.1.1 support in a Python 2.7 release." These changes are bac

Re: [Python-Dev] Adding test.support.safe_rmpath()

On 14Feb.2019 0948, Brett Cannon wrote: > On Thu, Feb 14, 2019 at 7:26 AM Giampaolo Rodola' > wrote: > Extra: an argument in favor of using tempfile.mkdtemp() instead of > TESTFN is parallel testing, but I think we're not using it. > > > With -j you can do para

[Python-Dev] buildbottest on Android emulator with docker

The following command runs the buildbottest on an Android emulator with docker (it will use a little bit more than 11 GB): $ docker run -it --privileged xdegaye/abifa:r14b-24-x86_64-master This command does: * pull an image from the Docker hub (only the first time that the command is run,

[Python-Dev] Python 3.8.0a1 with sqlite 3.27.1 -> OK

Hi all, I wanted to test with the new version of SQLite3 3.27.1 and there is no issue (compiled with a debian:latest docker image and the last version of 3.27.1). Sorry, it's not a bug, I wanted to inform you there is no issue with the last stable version of SQLite3. Have a nice week-end, St

Re: [Python-Dev] Adding test.support.safe_rmpath()

On Thu, Feb 14, 2019 at 6:48 PM Brett Cannon wrote: > > With -j you can do parallel testing and I know I always run with that on. > But TESTFN does *attempt *to account for that > >

Re: [Python-Dev] Proposed dates for Python 3.4.10 and Python 3.5.7

I wrote fixes: Le ven. 15 févr. 2019 à 12:28, Victor Stinner a écrit : > https://python-security.readthedocs.io/vuln/ssl-crl-dps-dos.html 3.5: https://github.com/python/cpython/pull/11867 3.4: https://github.com/python/cpython/pull/11868 > https://python-security.readthedocs.io/vuln/pickle-load

Re: [Python-Dev] Proposed dates for Python 3.4.10 and Python 3.5.7

Hi, Le ven. 15 févr. 2019 à 12:07, Miro Hrončok a écrit : > I've checked Fedora CVE bugs against python 3.4 and 3.5. Here is one missing I > found: > > CVE-2018-20406 https://bugs.python.org/issue34656 > memory exhaustion in Modules/_pickle.c:1393 > Marked as resolved, but I don't see it fixed on

Re: [Python-Dev] Proposed dates for Python 3.4.10 and Python 3.5.7

On 15. 02. 19 3:29, Larry Hastings wrote: If you have anything you think needs to go into the next 3.5, or the final 3.4, and it's /not/ listed above, please either file a GitHub PR, file a release-blocker bug on bpo, or email me directly. I've checked Fedora CVE bugs against python 3.4 and 3