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 machine

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 s

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 py

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] 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

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 li

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 aroun

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 au

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

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 co

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 just

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 tearDown(

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 >> te

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 nee

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 > > mailto: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 tearD

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] 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 fo

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 s

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] 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 t

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 wi

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] 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 wr

[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 co

[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 get_target_pl

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 https:

[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.