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

On Thu, Feb 14, 2019 at 12:43 AM Antoine Pitrou wrote: > > On Wed, 13 Feb 2019 17:32:44 -0800 > Nathaniel Smith wrote: > > On Wed, Feb 13, 2019 at 3:02 PM Steven D'Aprano wrote: > > > > > > On Wed, Feb 13, 2019 at 05:16:54PM -0500, Terry Reedy wrote: > > > > > > > It appears python is already

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

On 2/13/19 4:24 PM, Petr Viktorin wrote: I think it's time for another review. [...] Please see this PR for details and a suggested change: https://github.com/python/peps/pull/893 Summary of the thread so far. Antoine Pitrou noted that the PEP should acknowledge that there are now years of

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

On Wed, 13 Feb 2019 17:32:44 -0800 Nathaniel Smith wrote: > On Wed, Feb 13, 2019 at 3:02 PM Steven D'Aprano wrote: > > > > On Wed, Feb 13, 2019 at 05:16:54PM -0500, Terry Reedy wrote: > > > > > It appears python is already python3 for a large majority of human users > > > (as opposed to

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

Hi Petr, I would like to add this issue from the devguide where I ask if we need to use python or python3 in the documentation. https://github.com/python/devguide/issues/208 -- Stéphane Wirtel - https://wirtel.be - @matrixise ___ Python-Dev mailing

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

On Thu, 14 Feb 2019 00:57:36 -0500 Jason Swails wrote: > > I literally just ran into this problem now. Part of a software suite I've > written uses Python to fetch updates during the installation process. Due > to the target audience, it needs to access the system Python (only), and > support

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

— Twitter: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ > On 13 Feb 2019, at 16:10, Giampaolo Rodola' wrote: > > > > On Wed, Feb 13, 2019 at 2:27 PM Ronald Oussoren > wrote: > > >> On 13 Feb 2019, at 13:24, Giampaolo Rodola' >

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

> On Feb 14, 2019, at 3:44 AM, Antoine Pitrou wrote: > > On Thu, 14 Feb 2019 00:57:36 -0500 > Jason Swails wrote: >> >> I literally just ran into this problem now. Part of a software suite I've >> written uses Python to fetch updates during the installation process. Due >> to the target

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

On Thu, Feb 14, 2019, 02:47 Ronald Oussoren via Python-Dev < python-dev@python.org wrote: > > I usually use shutil.rmtree for tests that need to create temporary files, > and create a temporary directory for those files (that is, use > tempfile.mkdtemp in setUp() and use shutil.rmtree in

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

On 13.02.19 16:24, Petr Viktorin wrote: > PEP 394 says: > >> This recommendation will be periodically reviewed over the next few >> years, and updated when the core development team judges it >> appropriate. As a point of reference, regular maintenance releases >> for the Python 2.7 series will

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

On 2/13/19 5:45 PM, Victor Stinner wrote: Some more context about Petr's change, Fedora, RHEL and Red Hat. [...] Fedora could switch "python" to Python 3 now*, if the PEP changes to allow it. * "now" has a release date of around October 2019. The next release after that should then be

Re: [Python-Dev] datetime.timedelta total_microseconds

I don't think it's totally unreasonable to have other total_X() methods, where X would be days, hours, minutes and microseconds, but it also doesn't seem like a pressing need to me. I think the biggest argument against it is that they are all trivial to implement as necessary, because they're

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

On Thu, Feb 14, 2019 at 3:25 PM Eric Snow wrote: > On Thu, Feb 14, 2019, 02:47 Ronald Oussoren via Python-Dev < > python-dev@python.org wrote: > >> >> I usually use shutil.rmtree for tests that need to create temporary >> files, and create a temporary directory for those files (that is, use >>

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

I am glad this resurfaced as back in September I proposed updated that very old PEP but I got rejected. https://github.com/python/peps/pull/785 The main issue is that most distros will not fix it until PEP is refreshed because most of them do want to

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

On 14/02/2019 14:56, Giampaolo Rodola' wrote: On Thu, Feb 14, 2019 at 3:25 PM Eric Snow > wrote: On Thu, Feb 14, 2019, 02:47 Ronald Oussoren via Python-Dev mailto:python-dev@python.org> wrote: I usually use shutil.rmtree for tests that

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

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 current state seems is still the same that Debian > doesn't > want to ship a python symlink after the Python2 removal. The other

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

On Thu, Feb 14, 2019 at 4:03 PM Tim Golden wrote: > On 14/02/2019 14:56, Giampaolo Rodola' wrote: > > > > > > On Thu, Feb 14, 2019 at 3:25 PM Eric Snow > > wrote: > > > > On Thu, Feb 14, 2019, 02:47 Ronald Oussoren via Python-Dev > >

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

On 14/02/2019 15:24, Giampaolo Rodola' wrote: On Thu, Feb 14, 2019 at 4:03 PM Tim Golden > wrote: On 14/02/2019 14:56, Giampaolo Rodola' wrote: > > > On Thu, Feb 14, 2019 at 3:25 PM Eric Snow mailto:ericsnowcurren...@gmail.com> >

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

On Thu, Feb 14, 2019 at 10:49 AM Ronald Oussoren via Python-Dev < python-dev@python.org> wrote: > I usually use shutil.rmtree for tests that need to create temporary files, > and create a temporary directory for those files (that is, use > tempfile.mkdtemp in setUp() and use shutil.rmtree in

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

On 13.02.19 17:20, Victor Stinner wrote: > Hi, > > I'm a (strong) supporter of providing a "python" command which would > be the latest Python version! This very much depends on what is working with the latest Python version, and what amount of third party packages your distro has to support. It

[Python-Dev] An update on heap-allocated types

I’ll be adding a change to move the Py_INCREF of heap allocated types from PyType_GenericAlloc to PyObject_Init. You can follow the discussion and/or add comments to: https://bugs.python.org/issue35810. This change will make types created through PyType_FromSpec behave like classes in managed

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

As part of adding ARM32 support for Windows, we need to enable cross-compilation in distutils. This is easy enough, though it requires somehow getting the target platform as well as the current platform. Right now, the change at https://github.com/python/cpython/pull/11774 adds a

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

On Thu, Feb 14, 2019 at 11:38 AM Steve Dower wrote: > As part of adding ARM32 support for Windows, we need to enable > cross-compilation in distutils. This is easy enough, though it requires > somehow getting the target platform as well as the current platform. > > Right now, the change at

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

On Thu, Feb 14, 2019 at 7:50 AM 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 current state seems is still the same that Debian > doesn't > > want

Re: [Python-Dev] datetime.timedelta total_microseconds

On Thu, Feb 14, 2019 at 9:07 AM Paul Ganssle wrote: > I don't think it's totally unreasonable to have other total_X() methods, > where X would be days, hours, minutes and microseconds > I do. I was against adding the total_seconds() method to begin with because the same effect can be achieved

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

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 current state seems is still the same that Debian > doesn't > > want to

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

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 this is all hypothetical anyway , I’d more likely expect to only

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

On Thu, Feb 14, 2019 at 7:26 AM Giampaolo Rodola' wrote: > > > On Thu, Feb 14, 2019 at 4:03 PM Tim Golden wrote: > >> On 14/02/2019 14:56, Giampaolo Rodola' wrote: >> > >> > >> > On Thu, Feb 14, 2019 at 3:25 PM Eric Snow > > > wrote: >> > >> > On Thu, Feb

Re: [Python-Dev] datetime.timedelta total_microseconds

Ah yes, good point, I forgot about this because IIRC it's not supported in Python 2.7, so it's not a particularly common idiom in polyglot library code. Obviously any new methods would be Python 3-only, so there's no benefit to adding them. Best, Paul On 2/14/19 1:12 PM, Alexander Belopolsky

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

Howdy howdy!  It's time to make the next bugfix release of 3.5--and the /final/ release /ever/ of Python 3.4. Here's the schedule I propose: 3.4.10rc1 and 3.5.7rc1 - Saturday March 2 2019 3.4.10 final and 3.5.7 final - Saturday March 16 2019 What's going in these releases?  Not much.