[Python-Dev] Re: PEP 632: Deprecate distutils module
On 9/4/2020 6:00 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. Besides upgrades of existing systems, there are also new installs to consider. To totally remove this functionality is force such new systems to continue using older versions. This is not hypothetical hyperbolic in the least. In the software field I work in, I deal with limited internet connectivity all the time. My single biggest software development problem is software dependencies that assume a full blown internet connection under all circumstances. Even in 2020, that is not always wanted or advisable. --Edwin Zimmerman > > On Fri, Sep 04, 2020 at 02:56:07PM -0700, Emily Bowman wrote: >> On Fri, Sep 4, 2020 at 10:31 AM Stefan Krah wrote: >> >>> All the time, especially when I'm writing them. I imagine that there's >>> a huge amount of internal company code that discourages use of pip >>> installed packages as well. Or has an air-gapped network in the first >>> place. >>> >> That's wildly hyperbolic; not only will Python retain distutils through >> 3.11, any "airgapped" build will rest on an existing build that cannot be >> upgraded, so dependencies are a moot point. > ___ > 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/7ONUZMXXBFVWZPO6OSY634WNZ2ZC4FSU/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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/C4INWCK4QSVVCJDTHCO6R4OKME65VU4Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 632: Deprecate distutils module
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. On Fri, Sep 04, 2020 at 02:56:07PM -0700, Emily Bowman wrote: > On Fri, Sep 4, 2020 at 10:31 AM Stefan Krah wrote: > > > > > All the time, especially when I'm writing them. I imagine that there's > > a huge amount of internal company code that discourages use of pip > > installed packages as well. Or has an air-gapped network in the first > > place. > > > > That's wildly hyperbolic; not only will Python retain distutils through > 3.11, any "airgapped" build will rest on an existing build that cannot be > upgraded, so dependencies are a moot point. ___ 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/7ONUZMXXBFVWZPO6OSY634WNZ2ZC4FSU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 632: Deprecate distutils module
On Fri, Sep 4, 2020 at 10:31 AM Stefan Krah wrote: > > All the time, especially when I'm writing them. I imagine that there's > a huge amount of internal company code that discourages use of pip > installed packages as well. Or has an air-gapped network in the first > place. > That's wildly hyperbolic; not only will Python retain distutils through 3.11, any "airgapped" build will rest on an existing build that cannot be upgraded, so dependencies are a moot point. -Em ___ 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/NXWL4UMLBOXAEMI4S2VTJNW3CVNIHY2Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2020-08-28 - 2020-09-04)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7692 (+20)
closed 45764 (+44)
total 53456 (+64)
Open issues with patches: 3129
Issues opened (44)
==
#41657: Refactor for object source files variable in Makefile
https://bugs.python.org/issue41657 opened by ElianMariano
#41658: http.client not allowing non-ascii in headers
https://bugs.python.org/issue41658 opened by yellalena
#41659: PEG discrepancy on 'if {x} {a}: pass'
https://bugs.python.org/issue41659 opened by gvanrossum
#41660: multiprocessing.Manager objects lose connection info
https://bugs.python.org/issue41660 opened by tim.peters
#41661: os.path.relpath does not document ValueError on Windows with d
https://bugs.python.org/issue41661 opened by andymaier
#41662: Bugs in binding parameters in sqlite3
https://bugs.python.org/issue41662 opened by serhiy.storchaka
#41663: Support Windows pseudoterminals in pty and termios modules
https://bugs.python.org/issue41663 opened by cs01
#41667: The python PEG generator incorrectly handles empty sequences i
https://bugs.python.org/issue41667 opened by pablogsal
#41669: Case mismatch between "include" and "Include"
https://bugs.python.org/issue41669 opened by indygreg
#41670: ceval traces code differently with USE_COMPUTED_GOTOS
https://bugs.python.org/issue41670 opened by nedbat
#41671: inspect.getdoc/.cleandoc doesn't always remove trailing blank
https://bugs.python.org/issue41671 opened by RalfM
#41672: imaplib: wrong return type documented
https://bugs.python.org/issue41672 opened by norbertcyran
#41673: Result of multiprocessing.heap.BufferWrapper.create_memoryview
https://bugs.python.org/issue41673 opened by Eric Wieser
#41676: asyncio.Event.wait broken link from asyncio.Event
https://bugs.python.org/issue41676 opened by graingert
#41677: os.access() doesn't recognize lack of permissions on an SMB mo
https://bugs.python.org/issue41677 opened by mvpel
#41680: Turtles in Python 3.8.5 crashes OSX 10.14.6
https://bugs.python.org/issue41680 opened by dulcimoo
#41682: test_asyncio: Proactor test_sendfile_close_peer_in_the_middle_
https://bugs.python.org/issue41682 opened by aeros
#41684: argparse: unexpected subparser behaviour on parse_args with na
https://bugs.python.org/issue41684 opened by lucca.ruhland
#41686: C++ Embedded 'time.sleep()' is not working on Windows host due
https://bugs.python.org/issue41686 opened by hafizbilal100
#41687: sendfile implementation is not compatible with Solaris
https://bugs.python.org/issue41687 opened by kulikjak
#41688: Document how **= does not fall back on **
https://bugs.python.org/issue41688 opened by brett.cannon
#41692: Deprecate immortal interned strings: PyUnicode_InternImmortal(
https://bugs.python.org/issue41692 opened by vstinner
#41695: http.cookies.SimpleCookie.parse could not parse cookies when o
https://bugs.python.org/issue41695 opened by brayer.benoit
#41696: asyncio.run interacts surprisingly with debug mode
https://bugs.python.org/issue41696 opened by hauntsaninja
#41698: io.[Text]IOBase.seek doesn't take keyword parameter - revisite
https://bugs.python.org/issue41698 opened by andymaier
#41699: Potential memory leak with asyncio and run_in_executor
https://bugs.python.org/issue41699 opened by sophia2
#41701: Buildbot web page: connection lost after 1 minute, then displa
https://bugs.python.org/issue41701 opened by vstinner
#41702: Inconsistent behaviour in strftime
https://bugs.python.org/issue41702 opened by valdemarrolfsen
#41703: Most bytecode changes are absent from Python 3.9 What's new
https://bugs.python.org/issue41703 opened by mdartiailh
#41704: logging module needs some form of introspection or debugging s
https://bugs.python.org/issue41704 opened by jackjansen
#41705: os.makedirs fails on long-path UNC-paths if it is the first su
https://bugs.python.org/issue41705 opened by Safihre
#41706: docs: operator dunder (`__add__`, et al.) invocations describe
https://bugs.python.org/issue41706 opened by wchargin
#41707: Builtins like int() and float() should not blindly treat buffe
https://bugs.python.org/issue41707 opened by amohr
#41708: request make uninstall target
https://bugs.python.org/issue41708 opened by jeffs
#41710: Timeout is affected by jumps in system time
https://bugs.python.org/issue41710 opened by wocket
#41711: Socker send method throws a timeout exception
https://bugs.python.org/issue41711 opened by pppig
#41712: REDoS in purge
https://bugs.python.org/issue41712 opened by yetingli
#41713: _signal module leak: test_interpreters leaked [1424, 1422, 142
https://bugs.python.org/issue41713 opened by vstinner
#41714: multiprocessing.Queue deadlock
https://bugs.python.org/issue41714 opened by rpurdie
#41715: REDoS in c_analyzer
[Python-Dev] Re: PEP 632: Deprecate distutils module
On Fri, Sep 04, 2020 at 01:10:37PM -0400, Paul Ganssle wrote: > On 9/4/20 12:45 PM, Stefan Krah wrote: > > Since distutils does not change, why remove it? It is a lot of work > > for people with little gain. > > If we don't remove it, we should at least freeze the bug component so > that people cannot report bugs in distutils. Triaging these bugs alone > is a decent amount of work. We should probably also set up a Bedevere to > auto-reject PRs that touch distutils files (since telling people that > distutils is frozen and no longer maintained is effort as well), and > disable distutils in the CI so that it does not generate work for people > maintaining the buildbots. That is fine, but also note that Victor reported a CI issue introduced by the external setuptools package. > > I'd really like to build C extensions without downloading an external > > package. > How often do you actually build extensions without building or > installing external packages? All the time, especially when I'm writing them. I imagine that there's a huge amount of internal company code that discourages use of pip installed packages as well. Or has an air-gapped network in the first place. > > Features like C++ support have not been worked on for more than a > > decade. Are the setuptools maintainers planning to address these > > issues now? > > > Considering that we /aren't/ adding anything to distutils today, the > chances of this happening in setuptools are pretty much strictly better > than in distutils. Given the time constraints that everyone (rightfully!) has, I'd say the chances are rather low. My point was that features should not be a reason for deprecating distutils. Stefan Krah ___ 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/6NSEX5DXKUT2W5O5OPKCAQUOPCIDGQBA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 632: Deprecate distutils module
On 9/4/20 12:45 PM, Stefan Krah wrote:
> Since distutils does not change, why remove it? It is a lot of work
> for people with little gain.
If we don't remove it, we should at least freeze the bug component so
that people cannot report bugs in distutils. Triaging these bugs alone
is a decent amount of work. We should probably also set up a Bedevere to
auto-reject PRs that touch distutils files (since telling people that
distutils is frozen and no longer maintained is effort as well), and
disable distutils in the CI so that it does not generate work for people
maintaining the buildbots.
> I'd really like to build C extensions without downloading an external
> package.
How often do you actually build extensions without building or
installing external packages? You don't use `pip install` or PEP 517
builds? Just legacy build and installs? Do you not build or release
wheels (which requires the `wheel` package)? Are you planning to upload
artifacts to PyPI — if so, won't you need an external package (or at
least a maintained package that can keep up with the APIs? Before we
deprecated and removed it in setuptools, setup.py upload was causing
problems with the metadata it uploaded — we may need to ban
distutils-created packages from PyPI in order to keep PyPI going).
> Features like C++ support have not been worked on for more than a
> decade. Are the setuptools maintainers planning to address these
> issues now?
>
Considering that we /aren't/ adding anything to distutils today, the
chances of this happening in setuptools are pretty much strictly better
than in distutils.
>
>> * Modules/_decimal/tests/formathelper.py
> elif find_executable('locale'):
> locale_list = subprocess.Popen(["locale", "-a"],
> stdout=subprocess.PIPE).communicate()[0]
>
> One of the many things that just work out of the box. -10 on removing
> distutils from the stdlib. Freezing it is fine.
>
>
>
> Stefan Krah
>
>
> ___
> 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/6LQN5OAJQSEJS6YHRZNK4QORJXCHLPHA/
> Code of Conduct: http://python.org/psf/codeofconduct/
signature.asc
Description: OpenPGP digital signature
___
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/C6UWPNN2YLN5RRT54DWETQLY3VJVOSY5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Buildbot migrated to a new server
Thanks Victor and the rest of the Night’s Watch for all the work in our buildbots! El jue., 3 de sep. de 2020 a la(s) 12:08, Victor Stinner (vstin...@python.org) escribió: > > Hi, > > tl; dr Buildbots were unstable for 3 weeks but the issue is mostly resolved. > > > Since last January, the disk of the buildbot server was full every 2 > weeks and The Night’s Watch had to fix it in the darkness for you > (usually, remove JUnit files and restart the server). The old machine > only has 8 GB for the whole system and all data, whereas buildbot > workers produce large JUnit (XML) files (around 5 MB per file). > > Three weeks ago, Ernest W. Durbin III provided us a new machine with a > larger disk (60 GB) and installed PostgreSQL database (whereas SQLite > was used previously). He automated the installation of the machine, > but also (great new feature!) automated reloading the Buildbot server > when a new configuration is pushed in the Git repository. The > configuration is public and maintained at: > https://github.com/python/buildmaster-config/ > > The migration was really smooth, except that last week, we noticed > that workers started to be disconnected every minute, and then filled > their temporary directory with temporary compiler files leaked by > interrupted builds. Buildbot owners have to update their client > configuration and remove manually temporary files: > https://mail.python.org/archives/list/python-buildb...@python.org/thread/SZR2OLH67OYXSSADSM65HJYOIMFF44JZ/ > > Most buildbot worker configurations have been updated and the issue is > mostly resolved. > > There is another minor issue, HTTPS connections also closed after 1 > minute and so the web page is refreshed automatically every minute. > The load balancer configuration should be adjusted: > https://bugs.python.org/issue41701 > > Victor > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ > 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/DYUX5EEDAX3IO66QOICPK3VNEENSEIIQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org.ar/ Twitter: @facundobatista ___ 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/ZQRFBESKBCNOMFYZNJWSERUB477ZPYLW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 632: Deprecate distutils module
On 9/4/20 12:22 PM, Paul Moore wrote: > I believe that's correct. My main concern here is that removing > distutils from the stdlib won't have made that problem any better, it > will simply have transferred the responsibility onto the setuptools > maintainers. While I assume that they are comfortable with that, I > suspect they may take a different position on backwards compatibility > than core Python does (not least because one copy of setuptools has to > support multiple python versions, including alternative versions like > PyPy, whereas the stdlib copy only needs to handle the version of > Python it's distributed with). I think that it's /basically/ true that this move does transfer that responsibility over to setuptools, and I'm pretty sure that this is effectively handing over a big deprecation to deprecation specialists, since — at least as long as I've been involved with it — the process of maintaining setuptools is dominated by deprecating things (we do bugfixes and add features as well, of course, but there's a lot more to deprecate than in your typical project). That said, there are two major advantages to moving distutils into setuptools as the first step in making these "backwards-incompatible" changes (moving distutils into PyPI has similar advantages): 1. Deprecation notices start going out to /all/ supported versions of Python /immediately/ if they are using setuptools, making it easier to get the ecosystem to move together. 2. The fact that setuptools supports many versions of Python decouples the upgrade cycle of setuptools from the upgrade cycle of Python. Users can opt-in to new features by pinning a minimum version of setuptools (allowing them to take on migrations /without/ needing to upgrade their Python version), and if setuptools removes a feature they are counting on, they can pin a maximum version of setuptools mostly without disrupting their ability to upgrade Python versions. Related to this, setuptools can (and does) do more frequent updates, so it's easier to make a quick release undoing major breaking changes (or adding a new feature to work around them, etc). > I think the arguments in favour of this PEP from CPython's point of > view are fairly strong, but the arguments from the point of view of > the wider Python ecosystem are much less clear. I mostly agree that this is more useful for the people maintaining setuptools and distutils than it is for consumers of these packages, though that's not necessarily a bad thing. The downside is that we're going to make a bunch of breaking changes over the next few years (hopefully well-documented and with clear migration paths). The upside is that it will be easier for people to reap the benefits of the work we're doing to improve the packaging ecosystem (standardized build artifacts, bugfixes, etc). > Paul > ___ > 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/QRCA2AHOGZMQS45DANW4UGA63WTMJVQ6/ > Code of Conduct: http://python.org/psf/codeofconduct/ signature.asc Description: OpenPGP digital signature ___ 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/T7WR2LH4KSRN2PJE5C6Q35CVMLQ6MLFY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 632: Deprecate distutils module
I have been using standard distutils for large C extensions without
any issues.
Since distutils does not change, why remove it? It is a lot of work
for people with little gain.
I'd really like to build C extensions without downloading an external
package.
Features like C++ support have not been worked on for more than a
decade. Are the setuptools maintainers planning to address these
issues now?
> * Modules/_decimal/tests/formathelper.py
elif find_executable('locale'):
locale_list = subprocess.Popen(["locale", "-a"],
stdout=subprocess.PIPE).communicate()[0]
One of the many things that just work out of the box. -10 on removing
distutils from the stdlib. Freezing it is fine.
Stefan Krah
___
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/6LQN5OAJQSEJS6YHRZNK4QORJXCHLPHA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 632: Deprecate distutils module
On Fri, 4 Sep 2020 at 16:53, Fred Drake wrote: > > On Fri, Sep 4, 2020 at 11:02 AM Antoine Pitrou wrote: > > While I agree with the general suggestion of deprecating distutils as a > > publicly-visible module (in favour of encouraging users to rely on > > setuptools), it seems to me that the argument of facilitating the > > development of third-party build systems is what already encouraged the > > official policy of not adding features to distutils (more than 10 > > years ago, IIRC). > > My recollection is that we decided to stop changing distutils because > too many 3rd party extensions (often included directly in the packages > that needed them) using undocumented parts fo distutils directly > (since there was no substantially documented API for distutils in the > beginning). Every time anything changed, something was broken for > somebody. Since that affected not only the developers hooking in to > distutils but the users of their packages, touching distutils caused > too much pain. I believe that's correct. My main concern here is that removing distutils from the stdlib won't have made that problem any better, it will simply have transferred the responsibility onto the setuptools maintainers. While I assume that they are comfortable with that, I suspect they may take a different position on backwards compatibility than core Python does (not least because one copy of setuptools has to support multiple python versions, including alternative versions like PyPy, whereas the stdlib copy only needs to handle the version of Python it's distributed with). I think the arguments in favour of this PEP from CPython's point of view are fairly strong, but the arguments from the point of view of the wider Python ecosystem are much less clear. Paul ___ 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/QRCA2AHOGZMQS45DANW4UGA63WTMJVQ6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 632: Deprecate distutils module
On Fri, Sep 4, 2020 at 11:02 AM Antoine Pitrou wrote: > While I agree with the general suggestion of deprecating distutils as a > publicly-visible module (in favour of encouraging users to rely on > setuptools), it seems to me that the argument of facilitating the > development of third-party build systems is what already encouraged the > official policy of not adding features to distutils (more than 10 > years ago, IIRC). My recollection is that we decided to stop changing distutils because too many 3rd party extensions (often included directly in the packages that needed them) using undocumented parts fo distutils directly (since there was no substantially documented API for distutils in the beginning). Every time anything changed, something was broken for somebody. Since that affected not only the developers hooking in to distutils but the users of their packages, touching distutils caused too much pain. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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/6SO72DJWM7F77FFWGMIHCD2IWRMD5JAP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 632: Deprecate distutils module
On Fri, 4 Sep 2020 12:28:30 +0100 Steve Dower wrote: > > It will also help > promote the development of alternative build backends, which can now > be supported more easily thanks to PEP 517. While I agree with the general suggestion of deprecating distutils as a publicly-visible module (in favour of encouraging users to rely on setuptools), it seems to me that the argument of facilitating the development of third-party build systems is what already encouraged the official policy of not adding features to distutils (more than 10 years ago, IIRC). AFAIK, we're still waiting for those other build systems to appear. But, who knows, this time it will be different. Regards Antoine. ___ 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/SVXHWLJJA67H53VYYOMZFYUYLD7D2GAC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 632: Deprecate distutils module
Hi, Aha, someone proposed the idea :-) I know that Debian removed distutils from Python stdlib (it is a separate package) for a long time. You may mention https://github.com/pypa/distutils/ somewhere in the PEP: "Python Module Distribution Utilities extracted from the Python Standard Library". I don't know the future of this project since setuptools now also contains distutils. I would be nice to hear about setuptools maintainers here. setuptools 50.0.0 release didn't go well: it broke many use cases on Debian, Ubuntu and Fedora, etc. See: https://github.com/pypa/setuptools/issues especially https://github.com/pypa/setuptools/issues/2350 For example, Fedora does patch the stdlib distutils with a downstream-only patch, so pip installs into /usr/local rather than /usr. Well, there is likely a way to fix this issue in setuptools, but right now the situation is complicated. Le ven. 4 sept. 2020 à 13:37, Steve Dower a écrit : > 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. > (...) > 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. In practical terms, how Python 3.12 will build its extensions if it doesn't contain distutils anymore? Should we vendor a copy of setuptools, just for Python setup.py? So far, Python has no external dependency to be built. It makes it easy to build on various platforms. I would prefer to not have to download something from the Internet to build Python after I downloaded a Python tarball. We already have wheel packages of setuptools and pip in Lib/ensurepip/_bundled/. Victor ___ 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/75KYBX2BOW6TWQM7WR4QKXCFC6UUCRBJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 632: Deprecate distutils module
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.py * Lib/_aix_support.py * Lib/_bootsubprocess.py * Lib/_osx_support.py * Modules/_decimal/tests/formathelper.py As the distutils code is already included in setuptools, there is no need to republish it in any other form. Those who require access to the functionality should use setuptools or an alternative build backend. Backwards Compatibility === Code that imports distutils will no longer work from Python 3.12. The suggested migration path is to use the equivalent (though not
[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization
On Thu, 03 Sep 2020 18:17:12 - "Brandt Bucher" wrote: > Tim Peters wrote: > > `zip` then creates `n` 2-tuple objects, each of which lives only long > > enough to be unpacked into `x` and `y`... With "immediate" reclamation of > > garbage via refcounting, memory use is trival regardless of how large `n` > > is, as CPython reuses the same heap space over & over & over, ASAP. The > > space for each 2-tuple is reclaimed before `x-y` is computed... > > It's also worth noting that the current refcounting scheme allows for some > pretty sneaky optimizations under-the-hood. In your example, `zip` only ever > creates one 2-tuple, and keeps reusing it over and over: > > https://github.com/python/cpython/blob/c96d00e88ead8f99bb6aa1357928ac4545d9287c/Python/bltinmodule.c#L2623 This code is a bit concerning, it means the objects yielded by zip() can be kept alive inside the zip instance until the next iteration: olditem = PyTuple_GET_ITEM(result, i); PyTuple_SET_ITEM(result, i, item); Py_DECREF(olditem); (in case of error during iteration, it seems this may even be worse) And tuple allocation uses freelists for small sizes, so I'm not even sure how useful that optimization is. Regards Antoine. ___ 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/TJUYG2WLT3J32NVZGATKRHJMPHZVXOV2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On 30/07/2020 00:34, Nick Coghlan wrote: the proposed name binding syntax inherently conflicts with the existing assignment statement lvalue syntax in two areas: * dotted names (binds an attribute in assignment, looks up a constraint value in a match case) * underscore targets (binds in assignment, wildcard match without binding in a match case) The former syntactic conflict presents a bigger problem, though, as it means that we'd be irrevocably committed to having two different lvalue syntaxes for the rest of Python's future as a language. +1 ___ 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/WLNMH7OFURYPL2E7YT5JRYXW7RLDGIH6/ Code of Conduct: http://python.org/psf/codeofconduct/
