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

On 2019-02-13, 23:33 GMT, Barry Warsaw wrote: > Perhaps. I just don’t think Python 4 is anything but distant > vaporware. There’s a cost to freaking everyone out that > Python 4 is coming and will be as disruptive as Python 3. > Calling Python 3.9+1 Python 4 feeds into that FUD for no > reas

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

On Wed, Feb 13, 2019 at 10:26 AM 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 Py

Re: [Python-Dev] datetime.timedelta total_microseconds

Oops. That isn't the TOTAL microseconds, but just the microseconds portion. Sorry for the confusion. On Wed, Feb 13, 2019 at 9:23 PM Henry Chen wrote: > Looks like timedelta has a microseconds property. Would this work for your > needs? > > In [12]: d > Out[12]: datetime.timedelta(0, 3, 398407)

Re: [Python-Dev] datetime.timedelta total_microseconds

Looks like timedelta has a microseconds property. Would this work for your needs? In [12]: d Out[12]: datetime.timedelta(0, 3, 398407) In [13]: d.microseconds Out[13]: 398407 On Wed, Feb 13, 2019 at 9:08 PM Richard Belleville via Python-Dev < python-dev@python.org> wrote: > In a recent code rev

[Python-Dev] datetime.timedelta total_microseconds

In a recent code review, the following snippet was called out as reinventing the wheel: _MICROSECONDS_PER_SECOND = 100 def _timedelta_to_microseconds(delta): return int(delta.total_seconds() * _MICROSECONDS_PER_SECOND) The reviewer thought that there must already exist a standard library

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

On 2/13/2019 10:25 PM, Steven D'Aprano wrote: I haven't come across this FUD about Python 4, I have, on StackOverflow, induced by people reading something like "deprecated now, removed in 4.0" -- Terry Jan Reedy ___ Python-Dev mailing list Pytho

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

On Wed, Feb 13, 2019 at 03:33:21PM -0800, Barry Warsaw wrote: > I just don’t think Python 4 is anything but distant vaporware. If Python 4 follows 3.9, that could be as little as 3-4 years away :-) > There’s a cost to freaking everyone out that Python 4 is coming and > will be as disruptive as

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

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 machines). > > > > https://www.jetbrains.com/research/python-developers-survey-2

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

Steven D'Aprano writes: > But even if representative, this survey only tells us what version > people are using, now how they invoke it. We can't conclude that the > command "python" means Python 3 for these users. We simply don't know > one way or another (and I personally wouldn't want to

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

On 2019-02-13, Terry Reedy wrote: > It appears python is already python3 for a large majority of human users (as > opposed to machines). IMHO, the question about where /usr/bin/python points is more important for machines than for humans. Think about changing /bin/sh to some different version of

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

On Feb 13, 2019, at 15:07, Victor Stinner wrote: > > Le mer. 13 févr. 2019 à 21:26, Barry Warsaw a écrit : >> I don’t think this should be conflated with PEP 394. IMHO, 3.10 is just >> fine. Python 4 should be reserved for some future mythical GIL-less >> interpreter or other major API break

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

On Wed, Feb 13, 2019 at 12:29 PM Barry Warsaw wrote: > I think we should aspire for this to be the case too, eventually. When > this has come up in the past, we’ve said that it’s not appropriate to > change PEP 394 until Python 2 is officially deprecated. OTOH, I appreciate > that distros and o

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

Le mer. 13 févr. 2019 à 21:26, Barry Warsaw a écrit : > I don’t think this should be conflated with PEP 394. IMHO, 3.10 is just > fine. Python 4 should be reserved for some future mythical GIL-less > interpreter or other major API breaking change. It might never happen. My point is that chan

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

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 machines). > > https://www.jetbrains.com/research/python-developers-survey-2018/ > Nearly 2 valid responses, Oct-Nov. They may be valid re

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

On 2/13/2019 3:26 PM, Barry Warsaw wrote: I personally would like for `python` to be the latest Python 3 version (or perhaps Brett’s launcher), `python2` to be Python 2.7 where installed (and not mandatory). `python3` would be an alias for the latest Python 3. It appears python is already p

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

On 2019-02-13, Barry Warsaw wrote: > I personally would like for `python` to be the latest Python 3 > version (or perhaps Brett’s launcher), `python2` to be Python 2.7 > where installed (and not mandatory). `python3` would be an alias > for the latest Python 3. To me, having 'py' on Unix would be

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

On Feb 13, 2019, at 08:20, Victor Stinner wrote: > I'm a (strong) supporter of providing a "python" command which would > be the latest Python version! I think we should aspire for this to be the case too, eventually. When this has come up in the past, we’ve said that it’s not appropriate to c

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

> On Feb 13, 2019, at 9:13 AM, Steve Dower > > I'm inclined to view "python" as the default, official command, with the > versioned ones being workarounds added by distributors. +1 — almost. I agree that “python” be the default, but it would be good to require (or at least highly encourage) that

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

On 13Feb2019 0820, Victor Stinner wrote: On my Windows VM, "python" is Python 3.7 :-) In virtual environments, "python" can also be Python 3 as well. I recall that I saw commands using "python" rather than "python3" in the *official* Python 3 documentation: see examples below (*). Problem: On Wi

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

Some more context about Petr's change, Fedora, RHEL and Red Hat. At the latest Language Summit (2018), Petr detailed the state of the migration to Python 3 and how Python 2 is and will be handled at Red Hat; "Linux distributions and Python 2" talk with Matthias Klose (who works on Debian/Ubuntu):

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

On Wed, 13 Feb 2019 17:18:15 +0100 Petr Viktorin wrote: > On 2/13/19 4:46 PM, Antoine Pitrou wrote: > > On Wed, 13 Feb 2019 16:24:48 +0100 > > Petr Viktorin wrote: > >> PEP 394 says: > >> > >> > This recommendation will be periodically reviewed over the next few > >> > years, and updated

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

Hi, I'm a (strong) supporter of providing a "python" command which would be the latest Python version! As php does nowadays (after previous issues with "php4" vs "php5".) I don't recall that perl had "perl4" vs "perl5", the command was always "perl", no? Same for Ruby: it was still "ruby" after f

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

On 2/13/19 4:46 PM, Antoine Pitrou wrote: On Wed, 13 Feb 2019 16:24:48 +0100 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, regu

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

On Wed, 13 Feb 2019 16:24:48 +0100 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-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

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 continue until at least 2020. I think it's time

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

On Wed, Feb 13, 2019 at 2:32 PM Victor Stinner wrote: > Bikeshedding: I suggest to remove "safe_" from the name, it's hard to > guarantee that removal is "safe", especially on Windows where a > removal can be blocked for many reasons. > > Victor > Agree. I actually meant "rmpath()" (which I used

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

On Wed, Feb 13, 2019 at 2:27 PM Ronald Oussoren wrote: > > > On 13 Feb 2019, at 13:24, Giampaolo Rodola' wrote: > > > Hello, > after discovering os.makedirs() has no unit-tests ( > https://bugs.python.org/issue35982) I was thinking about working on a PR > to increase the test coverage of fs-rela

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

Bikeshedding: I suggest to remove "safe_" from the name, it's hard to guarantee that removal is "safe", especially on Windows where a removal can be blocked for many reasons. Victor Le mer. 13 févr. 2019 à 13:28, Giampaolo Rodola' a écrit : > > > Hello, > after discovering os.makedirs() has no u

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

> On 13 Feb 2019, at 13:24, Giampaolo Rodola' wrote: > > > Hello, > after discovering os.makedirs() has no unit-tests > (https://bugs.python.org/issue35982 ) I > was thinking about working on a PR to increase the test coverage of > fs-related os.* functio

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

Hello, after discovering os.makedirs() has no unit-tests ( https://bugs.python.org/issue35982) I was thinking about working on a PR to increase the test coverage of fs-related os.* functions. In order to do so I think it would be useful to add a convenience function to "just delete something if it