[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

[Serhiy Storchaka]

04.09.20 13:40, Antoine Pitrou пише:
> And tuple allocation uses freelists for small sizes, so I'm not even
> sure how useful that optimization is.

I do not know about zip(), but I measured the overhead of tuple
allocation in comparison of reusing tuple in other code, and it was not
so small. Tuple *deallocation* adds a significant amount of overhead due
to using the trashcan mechanism.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NQDVIGDGOYV2EVN6DVDP4XFMQRVCD4GA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 632: Deprecate distutils module

[Ivan Pozdeev via Python-Dev]

As I wrote in https://stackoverflow.com/questions/25337706/setuptools-vs-distutils-why-is-distutils-still-a-thing/40176290#40176290, 
distutils has a responsibility that setuptools as a 3rd-party entity cannot fulfill -- to set the core standards for addon modules structure 
and interface and be guaranteed to be present and compatible with the Python distribution that it comes with.


If you are going to remove distutils, something else will need to fulfill these 
goals.


On 04.09.2020 14:28, Steve Dower wrote:

Hi all.

setuptools has recently adopted the entire codebase of the distutils module, so that they will be able to make improvements directly 
without having to rely on patching the standard library. As a result, we can now move forward with official deprecation (in 3.10) and 
removal (in 3.12) (noting that the distutils docs already recommend switching to setuptools).


Full text and discussion at 
https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134

I'm including the original text below, but won't be responding to all discussions here (though I'll periodically check in and skim read 
it, assuming things don't go way off track).


Also be aware that I already have some minor changes lined up that are not in this text. Refer to the discussion on Discourse if you need 
to see those.


Cheers,
Steve

---

PEP: 632
Title: Deprecate distutils module
Author: Steve Dower 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 03-Sep-2020
Post-History:


Abstract


The distutils module [1]_ has for a long time recommended using the
setuptools package [2]_ instead. Setuptools has recently integrated a
complete copy of distutils and is no longer dependent on the standard
library [3]_. Pip has silently replaced distutils with setuptools when
building packages for a long time already. It is time to remove it
from the (public part of the) standard library.


Motivation
==

distutils [1]_ is a largely undocumented and unmaintained collection
of utilities for packaging and distributing Python packages, including
compilation of native extension modules. It defines a configuration
format that describes a Python distribution and provides the tools to
convert a directory of source code into a source distribution, and
some forms of binary distribution. Because of its place in the
standard library, many updates can only be released with a major
release, and users cannot rely on particular fixes being available.

setuptools [2]_ is a better documented and well maintained enhancement
based on distutils. While it provides very similar functionality, it
is much better able to support users on earlier Python releases, and
can respond to bug reports more quickly. A number of platform-specific
enhancements already exist in setuptools that have not been added to
distutils, and there is been a long-standing recommendation in the
distutils documentation to prefer setuptools.

Historically, setuptools has extended distutils using subclassing and
monkeypatching, but has now taken a copy of the underlying code. [3]_
As a result, the second last major dependency on distutils is gone and
there is no need to keep it in the standard library.

The final dependency on distutils is CPython itself, which uses it to
build the native extension modules in the standard library (except on
Windows). Because this is a CPython build-time dependency, it is
possible to continue to use distutils for this specific case without
it being part of the standard library.

Deprecation and removal will make it obvious that issues should be
fixed in the setuptools project, and will reduce a source of bug
reports and test maintenance that is unnecessary. It will also help
promote the development of alternative build backends, which can now
be supported more easily thanks to PEP 517.


Specification
=

In Python 3.10 and 3.11, distutils will be formally marked as
deprecated. All known issues will be closed at this time.
``import distutils`` will raise a deprecation warning.

During Python 3.10 and 3.11, uses of distutils within the standard
library may change to use alternative APIs.

In Python 3.12, distutils will no longer be installed by ``make
install`` or any of the first-party distribution. Third-party
redistributors should no longer include distutils in their bundles or
repositories.

This PEP makes no specification on migrating the parts of the CPython
build process that currently use distutils. Depending on
contributions, this migration may occur at any time.

After Python 3.12 is started and when the CPython build process no
longer depends on distutils being in the standard library, the entire
``Lib/distutils`` directory and ``Lib/test/test_distutils.py`` file
will be removed from the repository.

Other references to distutils will be cleaned up. As of Python 3.9's
initial release, the following modules have references in code or
comments:

* Lib/ctypes/util.py
* Lib/site.py
* Lib/sysconfig.

[Python-Dev] Re: PEP 632: Deprecate distutils module

[Emily Bowman]

On Fri, Sep 4, 2020 at 3:11 PM Stefan Krah  wrote:

>
>
> It is not hyperbolic at all. You can get permissions for a certain set
> of modules (the stdlib), but not for PyPI packages.
>
> Of course the upgrade is not via the network, that is beside the point.
>

If you can update to a breaking Python version, but aren't allowed one
single point version of an external module, you have a process problem.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZDV5OHDEVH3DGBHLPRQIZ7CHBLYV4CLA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 632: Deprecate distutils module

[Emily Bowman]

On Sat, Sep 5, 2020 at 12:37 AM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> As I wrote in
> https://stackoverflow.com/questions/25337706/setuptools-vs-distutils-why-is-distutils-still-a-thing/40176290#40176290,
>
> distutils has a responsibility that setuptools as a 3rd-party entity
> cannot fulfill -- to set the core standards for addon modules structure
> and interface and be guaranteed to be present and compatible with the
> Python distribution that it comes with.
>
> If you are going to remove distutils, something else will need to fulfill
> these goals.


Obviously, the "something else" is setuptools, which has filled that niche
for well over a decade now, and shows no signs of going away anytime soon.
Maybe someday there might be a PEP 517 challenger, but for now, setuptools
isn't going anywhere even if distutils goes away.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QUA6ITJJ7366FKUVQH3ROBHBU7UMP2B2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASED] Python 3.5.10 is released

[Larry Hastings]

On behalf of the Python development community, I'm plesed to announce 
the availability of Python 3.5.10.


Python 3.5 is in "security fixes only" mode.  This new version only 
contains security fixes, not conventional bug fixes, and it is a 
source-only release.


Important Notice: The latest releases of Linux (Ubuntu 20.04, Fedora 32) 
ship with a new version of OpenSSL.  New versions of OpenSSL often 
include upgraded configuration requirements to maintain network 
security; this new version no longer finds Python 3.5's OpenSSL 
configuration acceptable.  As a result, most or all secure-transport 
networking libraries are broken in this release on systems where this 
new version of OpenSSL is deployed.  This means, for example, that seven 
(7) of the regression tests in the test suite now regularly fail.  Older 
versions of Linux, with older versions of OpenSSL installed, are 
unaffected.  We're aware of the problem.  Unfortunately, as 3.5 is 
nearly completely out of support, it has become very low priority, and 
we've been unable to find the resources to get the problem fixed.  It's 
possible that these problems simply won't be fixed in 3.5 before it 
reaches its end-of-life.  As always we recommend upgrading to the latest 
Python release wherever possible.


Python 3.5 will reach its "end of life" at the end of September 2020.  
If there are no security patches filed for Python 3.5 after the release 
of Python 3.5.10, then Python 3.5.10 will be the final release of the 
3.5 series.



You can find Python 3.5.10 here:

   https://www.python.org/downloads/release/python-3510/



Cheers,


//arry/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YLE7EZPYYYQXV5FQSA5HSFTNDCNX2RQG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 622: Arrow for capture patterns

[Ram Rachum]

Hi everyone,

Sorry if this was proposed already. I looked here
https://www.python.org/dev/peps/pep-0622/#alternatives-for-constant-value-pattern,
search for "idea to make lookup semantics the default". I saw that a few
symbols like $ and ? were proposed, and I thought that maybe the annotation
syntax -> could indicate a capture expression, like so:

case x:
match Point(-> a, -> b):
...
match -> whatever:
do_something(whatever)

I like the arrow because it's easy to imagine the value "entering" the
variable. What do you think?


Thanks,
Ram.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/F22RLCDGKVMIBQKIJZAQYV3YCD45R2IQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 632: Deprecate distutils module

[Edwin Zimmerman]

On 9/5/2020 3:59 AM, Emily Bowman wrote:
> On Fri, Sep 4, 2020 at 3:11 PM Stefan Krah  > wrote:
>
>
>
> It is not hyperbolic at all. You can get permissions for a certain set
> of modules (the stdlib), but not for PyPI packages.
>
> Of course the upgrade is not via the network, that is beside the point.
>
>
> If you can update to a breaking Python version, but aren't allowed one single 
> point version of an external module, you have a process problem.
The point remains that these situations exist where it is simply impossible to 
run 'pip install xyz' due to network restrictions.  I know this firsthand 
because I have written software for enforcing total internet blocks.  Pushing 
Python to a pip-only module will preclude its use in such situations.  Again, 
this is not hypothetical.  This is the software world I deal with every day.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/B7ABAQAGQMBYICX3P7VAIK7OND73L6XU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 632: Deprecate distutils module

[Ivan Pozdeev via Python-Dev]

Then, as Victor said, it will have to be bundled into Python's codebase.

On 05.09.2020 11:06, Emily Bowman wrote:

On Sat, Sep 5, 2020 at 12:37 AM Ivan Pozdeev via Python-Dev mailto:python-dev@python.org>> wrote:

As I wrote in 
https://stackoverflow.com/questions/25337706/setuptools-vs-distutils-why-is-distutils-still-a-thing/40176290#40176290,
distutils has a responsibility that setuptools as a 3rd-party entity cannot 
fulfill -- to set the core standards for addon modules
structure
and interface and be guaranteed to be present and compatible with the 
Python distribution that it comes with.

If you are going to remove distutils, something else will need to fulfill 
these goals.


Obviously, the "something else" is setuptools, which has filled that niche for well over a decade now, and shows no signs of going away 
anytime soon. Maybe someday there might be a PEP 517 challenger, but for now, setuptools isn't going anywhere even if distutils goes away.

--
Regards,
Ivan
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NSYBWZQDGORSPYVH4KQ4NCY4FF675CP4/
Code of Conduct: http://python.org/psf/codeofconduct/