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

[Antoine Pitrou]

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 machines).
> > >
> > > https://www.jetbrains.com/research/python-developers-survey-2018/
> > > Nearly 2 valid responses, Oct-Nov.  
> >
> > They may be valid responses, but we don't know if they are
> > representative of the broader Python community. Its a self-selected
> > survey of people which always makes the results statistically suspect.
> >
> > (By definition, an Internet survey eliminates responses from people who
> > don't fill out surveys on the Internet.)
> >
> > 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 hazard a guess.)  
> 
> Can we gather data? What if pip started reporting info on how it was
> run when contacting pypi?

The most important information pip should report is whether it's
running on a CI platform (should be doable by looking at a few
environment variables, at least for the most popular platforms).
Currently nobody knows what the PyPI download stats mean, because they
could be 99% human or 99% CI.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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 systems as old as RHEL 5 (Python 2.4 and later, including Python
> 3.x in the same code base, using nothing but the stdlib).  The shebang line
> was "#!/usr/bin/env python"
> 
> It's been working for years, but was only now reported broken by a user
> that upgraded their Ubuntu distribution and suddenly had no "python"
> executable anywhere.  But they had python3.
> 
> I suspect suddenly not having any "python" executable in a Linux system
> will screw up a lot more people than just me.  The workaround was ugly.

I'm not sure what you mean.  Isn't the workaround to install Python 2
in this case?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nathaniel Smith]

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 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 responses, but we don't know if they are
> > > representative of the broader Python community. Its a self-selected
> > > survey of people which always makes the results statistically suspect.
> > >
> > > (By definition, an Internet survey eliminates responses from people who
> > > don't fill out surveys on the Internet.)
> > >
> > > 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 hazard a guess.)
> >
> > Can we gather data? What if pip started reporting info on how it was
> > run when contacting pypi?
>
> The most important information pip should report is whether it's
> running on a CI platform (should be doable by looking at a few
> environment variables, at least for the most popular platforms).
> Currently nobody knows what the PyPI download stats mean, because they
> could be 99% human or 99% CI.

I agree :-) https://github.com/pypa/pip/issues/5499#issuecomment-406840712

That's kind of orthogonal to this discussion though.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Petr Viktorin]

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
established usage of `python` as Python 3 for many conda users, often as 
the "main" Python.


Victor Stinner expressed support for "python" being the latest Python 
version, citing PHP, Ruby, Perl; containers; mentions of "python" in our 
docs.


Steve Dower later proposed concrete points how to make "python" the 
default command:

  * our docs should say "python" consistently
  * we should recommend that distributors use the same workaround
  * our docs should describe the recommended workaround in any places 
people are likely to first encounter it (tutorial, sys.executable, etc.)


Chris Barker added that "python3" should still be available, even if 
"python" is default.


Barry Warsaw gave a +1 to making "python" default, noting that there 
were plans to change this when Python 2 is officially deprecated. But 
distros need to make decisions about 2020 now.


Chris Barker noted that users won't see any discuntinuity in 2020. 
That's just a date support from CPython devs ends.


Victor pointed to discussions on 4.0 vs. 3.10. (I'll ignore discussions 
on 4.0 in this summary.)

Victor also posted some interesting info and links on Fedora and RHEL.
There was a discussion on the PSF survey about how many people use 
Python 3. (I'll ignore this sub-thread, it's not really about the 
"python" command.)


Steve noted that the Windows Store package of Python 3 provides 
"python", but he is still thinking how to make this reasonable/reliable 
in the full installer.


Several people think "py" on Unix would be a good thing. Neil 
Schemenauer supposes we would encourage people to use it over 
"python"/"python2"/"python3", so "python" would be less of an issue.


Neil Schemenauer is not opposed to making "python" configurable or 
eventually pointing it to Python 3.


Jason Swails shared experience from running software with a 
"#!/usr/bin/env python" shebang on a system that didn't have Python 2 
(and followed the PEP, so no "python" either). The workaround was ugly.


-

Since this list is public, I'd like to remind all readers that it is 
full of people who work extensively with Python 3, and tend to drive it 
forward at any opportunity. (Myself included, but on this thread I'll 
leave the arguments to someone else – they're covered adequately.)


Thoughts of Python developers are important, but we're not hearing any 
other voices. Perhaps everyone with a different opinion has already 
self-selected out.


I don't know of a good place for this discussion, and I'm not a good 
person to give arguments to support the original "python" should be 
Python 2 direction. (But if I did, I imagine posting them here would 
feel a bit scary.)
But I would not be surprised, or annoyed, if the Council had a private 
discussion and pronounced "No, sorry, not yet".


Anyway, how should this be decided? Where should it be discussed?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ronald Oussoren via Python-Dev]

—

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' > > 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.* functions. In order to do so I think it would be useful to 
>> add a convenience function to "just delete something if it exists", 
>> regardless if it's a file, directory, directory tree, etc., and include it 
>> into test.support module.
> 
> Something like shutil.rmtree() with ignore_errors=True?
> 
> shutil.rmtree() is about directories and can't be used against files. 
> support.rmpath() would take a path (meaning anything) and try to remove it.

You’re right.  

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()). That way I don’t have to adjust 
house-keeping code when I make changes to test code.

Ronald

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Stephane Wirtel]

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 list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Petr Viktorin]

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 around May 2020.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jason Swails]

 

> 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 audience, it needs to access the system Python (only), and
>> support systems as old as RHEL 5 (Python 2.4 and later, including Python
>> 3.x in the same code base, using nothing but the stdlib).  The shebang line
>> was "#!/usr/bin/env python"
>> 
>> It's been working for years, but was only now reported broken by a user
>> that upgraded their Ubuntu distribution and suddenly had no "python"
>> executable anywhere.  But they had python3.
>> 
>> I suspect suddenly not having any "python" executable in a Linux system
>> will screw up a lot more people than just me.  The workaround was ugly.
> 
> I'm not sure what you mean.  Isn't the workaround to install Python 2
> in this case?

I release the software, so the problem is not my machine, it’s others’. The 
installation process also fetches a local miniconda distribution for the Python 
utilities that are part of the program suite (and the python programs are 
optional and typically not installed when this suite is deployed on a 
supercomputer, for instance). But the software needs to check for updates 
before it does any of that (hence my concern — this script needs to be able to 
run before the user does *anything* else, including installing dependencies). 

This would also be the first time we’d have to give different installation 
instructions for different versions of the same Linux distro. 

The workaround from a users perspective is simple for me, but I can’t make that 
same assumption for all of my users. This is an impediment to keeping the user 
experience as simple as possible. 

Thanks,
Jason
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Matthias Klose]

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 doesn't have
to be the newest 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 for Ruby 2, no?
> Only Python and PHP used different program names depending on the
> language version, no? And PHP now moved back to a single "php"
> program.

it's not only upstreams doing that kind of versioned names; distros are doing
that to ease the pain for larger transitions.

> In the container and virtualenv era, it's now easy to get your
> favorite Python version for the "python" command.
> 
> On my Windows VM, "python" is Python 3.7 :-) In virtual environments,
> "python" can also be Python 3 as well.

maybe the PEP should recommend to have python3 in virtual environments as well?

Matthias
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Matthias Klose]

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 continue until at least 2020.
> 
> I think it's time for another review.
> I'm especially worried about the implication of these:
> 
> - If the `python` command is installed, it should invoke the same
>   version of Python as the `python2` command
> - scripts that are deliberately written to be source compatible
>   with both Python 2.x and 3.x [...] may continue to use `python` on
>   their shebang line.
> 
> So, to support scripts that adhere to the recommendation, Python 2
> needs to be installed :(

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.

For Ubuntu, I'm not sure if I want a python executable at all, because there is
not much progress in handling more than one python installation, so just using
python3 for the distro sounds fine.  pypi.org now recommends unconditionally
installing with pip, and pip is still happy to modify system installed packages
when asked, messing around with the distro packages.  But probably that kind of
users then install their own python symlink anyway.

For the Ubuntu 20.04 LTS release and the Debian bullseye release (maybe 2021), I
am trying to make sure that the python shebang isn't used by distro packages
anymore (either by removing python2 altogether, or by using the
python2/python2.7 shebangs).

Matthias
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime.timedelta total_microseconds

[Paul Ganssle]

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 unit conversions that
involve multiplication or division by constants, which is nowhere near
as complicated to implement as the original `total_seconds` method.
Here's the issue where total_seconds() was implemented, it doesn't seem
like there was any discussion of other total methods until after the
issue was closed: https://bugs.python.org/issue5788

I think the main issue is how "thick" we want the timedelta class to
be.  With separate methods for every unit, we have to maintain and
document 5 methods instead of 1, though the methods are trivial and the
documentation could maybe be shared.

If I had a time machine, I'd probably recommend an interface something
like this:

def total_duration(self, units='seconds'):
    return self._total_seconds() * _SECONDS_PER_UNIT[units]

I suppose it would be possible to move to that interface today, though I
think it would be mildly confusing to have two functions that do the
same thing (total_seconds and total_duration), which may not be worth it
considering that these functions are a pretty minor convenience.

Best,

Paul

On 2/14/19 12:05 AM, Richard Belleville via Python-Dev wrote:
> 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
> function
> that fulfills this functionality. After we had both satisfied
> ourselves that we
> hadn't simply missed something in the documentation, we decided that
> we had
> better raise the issue with a wider audience.
>
> Does this functionality already exist within the standard library? If
> not, would
> a datetime.timedelta.total_microseconds function be a reasonable
> addition? I
> would be happy to submit a patch for such a thing.
>
> Richard Belleville
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/paul%40ganssle.io


signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric Snow]

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()). That way
> I don’t have to adjust house-keeping code when I make changes to test code.
>

Same here.

-eric

>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Giampaolo Rodola']

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
>> tempfile.mkdtemp in setUp() and use shutil.rmtree in tearDown()). That way
>> I don’t have to adjust house-keeping code when I make changes to test code.
>>
>
> Same here.
>
> -eric
>
>>
What I generally do is avoid relying on tempfile.mkdtemp() and always use
TESTFN instead. I think it's cleaner as a pradigm because it's an incentive
to not pollute the single unit tests with  `self.addCleanup()` instructions
(the whole cleanup logic is always supposed to occur in setUp/tearDown):


TESTFN = support.TESTFN
TESTFN2 = TESTFN + '2'

class FilesystemTest(unittest.TestCase):

def setUp(self):
remove_file_or_dir(TESTFN)
remove_file_or_dir(TESTFN2)
tearDown = setUp

def test_mkdir(self):
...
def test_listdir(self):
...
def test_rename(self):
...

-- 
Giampaolo - http://grodola.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Golden]

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 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()). That way I don’t have to adjust
house-keeping code when I make changes to test code.


Same here.

-eric


What I generally do is avoid relying on tempfile.mkdtemp() and always 
use TESTFN instead. I think it's cleaner as a pradigm because it's an 
incentive to not pollute the single unit tests with  `self.addCleanup()` 
instructions (the whole cleanup logic is always supposed to occur in 
setUp/tearDown):


Must chime in here because I've been pushing (variously months & years 
ago) to move *away* from TESTFN because it generates numerous 
intermittent errors on my Windows setup. I've had several goes at 
starting to do that but a combination of my own lack of time plus some 
people's reluctance to go that route altogether has stalled the thing.


I'm not sure I understand the difference in cleanup/teardown terms 
between using tempfile and using TESTFN. The objections I've seen from 
people (apart, obviously, from test churn) are to do with building up 
testing temp artefacts on a possibly low-sized disk.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Giampaolo Rodola']

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@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()). That way I don’t have to adjust
> > house-keeping code when I make changes to test code.
> >
> >
> > Same here.
> >
> > -eric
> >
> >
> > What I generally do is avoid relying on tempfile.mkdtemp() and always
> > use TESTFN instead. I think it's cleaner as a pradigm because it's an
> > incentive to not pollute the single unit tests with  `self.addCleanup()`
> > instructions (the whole cleanup logic is always supposed to occur in
> > setUp/tearDown):
>
> Must chime in here because I've been pushing (variously months & years
> ago) to move *away* from TESTFN because it generates numerous
> intermittent errors on my Windows setup. I've had several goes at
> starting to do that but a combination of my own lack of time plus some
> people's reluctance to go that route altogether has stalled the thing.
>
> I'm not sure I understand the difference in cleanup/teardown terms
> between using tempfile and using TESTFN. The objections I've seen from
> people (apart, obviously, from test churn) are to do with building up
> testing temp artefacts on a possibly low-sized disk.
>
> TJG
>

I suppose you mean the intermittent failures are usually due to "file is
already in use by another process" correct? test.support's unlink(),
rmdir() and rmtree() functions already implement a retry-with-timeout logic
in order to prevent this issue. I suppose when this issue may still occur,
though, is when the file/handle is held by another process, meaning that
the unit-test probably forgot to terminate()/wait() a subprocess or should
have used support.read_children(). In summary, my approach is more "strict"
because it implies that unit-tests always do a proper cleanup.
tempfile.mkdtemp() may prevent failures but it may hide a unit-test which
doesn't do a proper file/dir cleanup and should have been fixed instead.
The drawback in practical terms is that orphaned test files are left behind.

Extra: an argument in favor of using tempfile.mkdtemp() instead of TESTFN
is parallel testing, but I think we're not using it.


-- 
Giampaolo - http://grodola.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Golden]

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>
 > >> 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 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()). That way I don’t have to adjust
 >         house-keeping code when I make changes to test code.
 >
 >
 >     Same here.
 >
 >     -eric
 >
 >
 > What I generally do is avoid relying on tempfile.mkdtemp() and
always
 > use TESTFN instead. I think it's cleaner as a pradigm because
it's an
 > incentive to not pollute the single unit tests with 
`self.addCleanup()`

 > instructions (the whole cleanup logic is always supposed to occur in
 > setUp/tearDown):

Must chime in here because I've been pushing (variously months & years
ago) to move *away* from TESTFN because it generates numerous
intermittent errors on my Windows setup. I've had several goes at
starting to do that but a combination of my own lack of time plus some
people's reluctance to go that route altogether has stalled the thing.

I'm not sure I understand the difference in cleanup/teardown terms
between using tempfile and using TESTFN. The objections I've seen from
people (apart, obviously, from test churn) are to do with building up
testing temp artefacts on a possibly low-sized disk.

TJG


I suppose you mean the intermittent failures are usually due to "file is 
already in use by another process" correct? test.support's unlink(), 


Occasionally (and those are usually down to a poorly-handled cleanup).

More commonly it's due to residual share-delete handles on those files, 
probably from indexing & virus checkers or TortoiseXXX cache handlers. 
Obviously I can (and to some extent do) try to mitigate those issues.


In short: reusing the same filepath over and over for tests which are 
run in quick succession doesn't seem like a good idea usually. That's 
commonly what TESTFN-based tests do (some do; some don't).


I'm 100% with you on strict clean-up, not leaving testing turds behind, 
not over-complicating simple tests with lost of framework. All that. But 
-- however it's done -- I'd prefer to move away from the test-global 
TESTFN approach.


I'm not at my dev box atm so can't pick out examples but I definitely 
have some :) I have no issue with your proposal here: better and simpler 
cleanup is A Good Thing. But it won't solve the problem of re-using the 
same test filepath again and again.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Joni Orponen]

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 tearDown()). That way
> I don’t have to adjust house-keeping code when I make changes to test code.
>

As tempfile provides context managers, should these be used internally for
something like this? Provide a decorator which passes in the temp file /
directory.

-- 
Joni Orponen
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Victor Stinner]

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 safer alternative is to start to provide "py" launcher on
Unix as well. Since it's something new, it's perfectly fine to decide
from the start to make it point to the latest Python version by
default.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Sorin Sbarnea]

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 follow PEPs.

There is still hope.

Cheers
Sorin

> On 13 Feb 2019, at 16:20, Victor Stinner  wrote:
> 
> 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 for Ruby 2, no?
> Only Python and PHP used different program names depending on the
> language version, no? And PHP now moved back to a single "php"
> program.
> 
> In the container and virtualenv era, it's now easy to get your
> favorite Python version for the "python" command.
> 
> 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 Windows, "python" is the right command. "python3" doesn't
> work (doesn't exist) on Windows. Should we write the doc for Windows
> or for Unix? Oooops.
> 
> There was an interesting discussion about the Python version following
> Python 3.9: Python 3.10 or Python 4? And what are the issues which
> would make us prefer 3.10 rather than 4.0?
> https://mail.python.org/pipermail/python-committers/2018-September/006152.html
> 
> One practical issue is that right now, six.PY3 is defined by "PY3 =
> sys.version_info[0] == 3" and so "if six.PY3:" will be false on Python
> 4.
> 
> Another interesting thing to mention is the Unix Python launcher
> ("py") written by Brett Cannon written in Rust:
> https://github.com/brettcannon/python-launcher
> 
> 
> (*) A few examples of "python" commands in the Python official documentation
> 
> "$ python prog.py -h"
> https://docs.python.org/dev/library/argparse.html
> 
> "$ python logctx.py"
> https://docs.python.org/dev/howto/logging-cookbook.html
> 
> "python setup.py install"
> https://docs.python.org/dev/install/index.html
> 
> "python --help"
> https://docs.python.org/dev/howto/argparse.html
> 
> "python setup.py build"
> https://docs.python.org/dev/extending/building.html
> 
> "exec python $0 ${1+"$@"}"
> https://docs.python.org/dev/faq/library.html
> 
> "python setup.py --help build_ext"
> https://docs.python.org/dev/distutils/configfile.html
> 
> Victor
> 
> Le mer. 13 févr. 2019 à 16:49, Antoine Pitrou  a écrit :
>> 
>> 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 2.7 series will continue until at least 2020.
>>> 
>>> I think it's time for another review.
>>> I'm especially worried about the implication of these:
>>> 
>>> - If the `python` command is installed, it should invoke the same
>>>   version of Python as the `python2` command
>>> - scripts that are deliberately written to be source compatible
>>>   with both Python 2.x and 3.x [...] may continue to use `python` on
>>>   their shebang line.
>>> 
>>> So, to support scripts that adhere to the recommendation, Python 2
>>> needs to be installed :(
>> 
>> I think PEP 394 should acknowledge that there are now years of
>> established usage of `python` as Python 3 for many conda users.
>> 
>> Regards
>> 
>> Antoine.
>> 
>> 
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: 
>> https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com
> 
> 
> 
> -- 
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/sorin.sbarnea%40gmail.com

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

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 ship /usr/bin/python.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Brett Cannon]

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 14, 2019, 02:47 Ronald Oussoren via Python-Dev
>> > mailto: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()). That way I don’t have to adjust
>> > house-keeping code when I make changes to test code.
>> >
>> >
>> > Same here.
>> >
>> > -eric
>> >
>> >
>> > What I generally do is avoid relying on tempfile.mkdtemp() and always
>> > use TESTFN instead. I think it's cleaner as a pradigm because it's an
>> > incentive to not pollute the single unit tests with
>> `self.addCleanup()`
>> > instructions (the whole cleanup logic is always supposed to occur in
>> > setUp/tearDown):
>>
>> Must chime in here because I've been pushing (variously months & years
>> ago) to move *away* from TESTFN because it generates numerous
>> intermittent errors on my Windows setup. I've had several goes at
>> starting to do that but a combination of my own lack of time plus some
>> people's reluctance to go that route altogether has stalled the thing.
>>
>> I'm not sure I understand the difference in cleanup/teardown terms
>> between using tempfile and using TESTFN. The objections I've seen from
>> people (apart, obviously, from test churn) are to do with building up
>> testing temp artefacts on a possibly low-sized disk.
>>
>> TJG
>>
>
> I suppose you mean the intermittent failures are usually due to "file is
> already in use by another process" correct? test.support's unlink(),
> rmdir() and rmtree() functions already implement a retry-with-timeout logic
> in order to prevent this issue. I suppose when this issue may still occur,
> though, is when the file/handle is held by another process, meaning that
> the unit-test probably forgot to terminate()/wait() a subprocess or should
> have used support.read_children(). In summary, my approach is more "strict"
> because it implies that unit-tests always do a proper cleanup.
> tempfile.mkdtemp() may prevent failures but it may hide a unit-test which
> doesn't do a proper file/dir cleanup and should have been fixed instead.
> The drawback in practical terms is that orphaned test files are left behind.
>
> 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 parallel testing and I know I always run with that on.
But TESTFN does *attempt *to account for that

by using the PID in the name.

Having said that, I do use tempfile like Eric, Ronald, and Tim when I write
tests as I have real-world experience using tempfile so I usually remember
to clean up versus TESTFN which is Python stdlib internals only and I have
to remember that it won't clean up itself.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Brett Cannon]

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 to ship a python symlink after the Python2 removal.
>
> The other safer alternative is to start to provide "py" launcher on
> Unix as well. Since it's something new, it's perfectly fine to decide
> from the start to make it point to the latest Python version by
> default.
>

Since it has come up a couple of times and in case people are curious, the
Python Launcher for UNIX is currently available at
https://crates.io/crates/python-launcher and the basics are there. I have
one more key feature to implement -- `py --list` -- before I view it as
having all the basics in place. Once I have --list done it will be trying
to tackle the hard issue of how to tie in things like PyPy or
non-PATH-installed interpreters into the launcher (which, since it is
configuration, people will bikeshed on forever about, so maybe I should
ignore people and solve it quickly ;) .
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime.timedelta total_microseconds

[Alexander Belopolsky]

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 with

delta / timedelta(seconds=1)

this is easily generalized to

delta / timedelta(X=1)

where X can be days, hours, minutes or microseconds.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Gustavo Carneiro]

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 ship a python symlink after the Python2 removal.
>
> The other safer alternative is to start to provide "py" launcher on
> Unix as well. Since it's something new, it's perfectly fine to decide
> from the start to make it point to the latest Python version by
> default.
>

While I like very much the idea of having `py` as command, does it really
need to be a wrapper command?  Why can't it simply be a symlink?

/usr/bin/py -> /usr/bin/python3

I worry about (1) startup time overhead of starting another process, (2)
added complexity of learning about py's additional command-line options, we
don't really need them, imho.


> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com
>


-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime.timedelta total_microseconds

[Paul Ganssle]

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 wrote:
>
>
> 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 with
>
> delta / timedelta(seconds=1)
>
> this is easily generalized to
>
> delta / timedelta(X=1)
>
> where X can be days, hours, minutes or microseconds.
>  


signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eddie Elizondo]

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 code. Thus, 
making CPython much safer.

Without this change, there are a couple of edge cases where the use of 
PyObject_{,GC}_New{,Var} does not correctly increase refcount. This leads to 
weird behavior, especially when migrating types from PyType_Ready to 
PyType_FromSpec. For example, consider a static type with tp_new = NULL and 
tp_dealloc = NULL. This type initializes instances through PyObject_New and 
never increases the type’s refcount. tp_dealloc will be a no-op since it's NULL 
and it's a static type. When this type is migrated to PyType_FromSpec, 
tp_dealloc will now inherit subtype_dealloc which decrefs the type. This leads 
to a crash.

For the vast majority of existing code this should not have a visible side 
effect. And, at worst, this will only cause some type to become immortal. I’ve 
added instructions in the “Porting to Python 3.8” to correctly account for this 
new incref along with examples. In general, there are only two cases that would 
require any modification:

  1.  If the type creates instances through PyObject_{,GC}_New{,Var} and the 
type manually increfs afterwards. The fix here is to remove that manual incref.
  2.  If the type has a custom tp_dealloc and it’s not decrefing the type. The 
fix here is that a custom tp_dealloc should ALWAYS decref the type.

Open to feedback/discussion so feel free to reply if you have any questions!

- Eddie Elizondo
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steve Dower]

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_platform() function for this and updates (as far as I 
can tell) all uses of get_platform() to use this instead. I would rather 
just change get_platform() to return the target platform.


The current docs are somewhat vague on exactly what this function does, 
and I suspect have been mostly written from an "always build from 
source" mentality that may have implied, but not explicitly considered 
cross-compilation.


https://docs.python.org/3/distutils/apiref.html#distutils.util.get_platform

"Return a string that identifies the current platform. This is used 
mainly to distinguish platform-specific build directories and 
platform-specific built distributions."


So it says "current" platform, explicitly says that "os.uname()" is the 
source, but then goes on to say:


"For non-POSIX platforms, currently just returns sys.platform."

Which is incorrect, as sys.platform is always "win32" always but 
get_platform() already returns "win-amd64" for 64-bit builds.


And also:

"For Mac OS X systems the OS version reflects the minimal version on 
which binaries will run (that is, the value of MACOSX_DEPLOYMENT_TARGET 
during the build of Python), not the OS version of the current system."


So it seems like this function is already returning "the default 
platform that should be used when building extensions" - ignoring bugs 
in libraries that monkeypatch distutils, the "--plat-name" option should 
entirely override the return value of this function.


Given this, does it seem to be okay to have it determine and return the 
target platform rather than the host platform? Right now, that would 
only affect the new target of building for win-arm32, but I would also 
like to update the documentation to make it more about how this value 
should be used rather than where it comes from.


Any objections or concerns?

Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Gregory P. Smith]

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://github.com/python/cpython/pull/11774
> adds a get_target_platform() function for this and updates (as far as I
> can tell) all uses of get_platform() to use this instead. I would rather
> just change get_platform() to return the target platform.
>
> The current docs are somewhat vague on exactly what this function does,
> and I suspect have been mostly written from an "always build from
> source" mentality that may have implied, but not explicitly considered
> cross-compilation.
>
> https://docs.python.org/3/distutils/apiref.html#distutils.util.get_platform
>
> "Return a string that identifies the current platform. This is used
> mainly to distinguish platform-specific build directories and
> platform-specific built distributions."
>
> So it says "current" platform, explicitly says that "os.uname()" is the
> source, but then goes on to say:
>
> "For non-POSIX platforms, currently just returns sys.platform."
>
> Which is incorrect, as sys.platform is always "win32" always but
> get_platform() already returns "win-amd64" for 64-bit builds.
>
> And also:
>
> "For Mac OS X systems the OS version reflects the minimal version on
> which binaries will run (that is, the value of MACOSX_DEPLOYMENT_TARGET
> during the build of Python), not the OS version of the current system."
>
> So it seems like this function is already returning "the default
> platform that should be used when building extensions" - ignoring bugs
> in libraries that monkeypatch distutils, the "--plat-name" option should
> entirely override the return value of this function.
>
> Given this, does it seem to be okay to have it determine and return the
> target platform rather than the host platform? Right now, that would
> only affect the new target of building for win-arm32, but I would also
> like to update the documentation to make it more about how this value
> should be used rather than where it comes from.
>
> Any objections or concerns?
>

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().

There are valid reasons for people to be expecting either target or current
return values from get_platform(), but I agree with you, having it return
the target platform *feels* more likely to be what people want.  It'd be
worth auditing a random sample of people's calls of this API in open source
projects to confirm that intuition.

-gps
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Larry Hastings]

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.  I have two outstanding PRs 
against 3.5:


   bpo-33127 GH-10994: Compatibility patch for LibreSSL 2.7.0
   bpo-34623 GH-9933: XML_SetHashSalt in _elementtree

and one PR against 3.4:

   bpo-34623 GH-9953: Use XML_SetHashSalt in _elementtree

I expect to merge all three of those, I just need to get around to it.  
There's one more recent security fix (bpo-35746, GH-11569) that  I want 
in these releases that still needs backporting.



And that's the entire list.  bpo-34623 is the only current release 
blocker for either 3.4 or 3.5--I'm not aware of anything else in the 
pipeline.  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.



Good night sweet Python 3.4, and flights of angels sing thee to thy rest!


//arry/

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com