[Python-Dev] Re: How To Get Started

On 28/07/2022 18.34, kiddkod...@gmail.com wrote: New coding bootcamp graduate here looking actively for my first programming job. In the meantime, I want to start contributing to open source which brought me here. But after consulting the Python's Developer Guide, I'm still faced with some

[Python-Dev] Re: [Python-Help] Unable to bootstrap Python 3 install

On 16/06/2022 16.29, Xavier de Gaye wrote: Victor Stinner wrote: > https://github.com/python/cpython/issues/66913 doesn't explain how to reproduce the issue, it only gives some info about what doesn't work. > I don't know how to reproduce the

[Python-Dev] Re: Migration plan for the distutils removal in Python 3.12

On 10/05/2022 13.18, Victor Stinner wrote: On Tue, May 10, 2022 at 11:28 AM Christian Heimes wrote: Right now, Python still uses distutils internally for multiple use cases. I propose to start with renaming the distutils package to _distutils in the stdlib: * https://github.com/python/cpython

[Python-Dev] Re: Migration plan for the distutils removal in Python 3.12

On 10/05/2022 09.53, Victor Stinner wrote: Hi, Two years ago, PEP 632 "Deprecate distutils module" was accepted: the distutils package was deprecated in Python 3.10 and scheduled for removal in Python 3.12. Questions. * Is the Python ecosystem ready for the distutils removal? How many projects

[Python-Dev] Re: Migration plan for the distutils removal in Python 3.12

On 10/05/2022 09.53, Victor Stinner wrote: Hi, Two years ago, PEP 632 "Deprecate distutils module" was accepted: the distutils package was deprecated in Python 3.10 and scheduled for removal in Python 3.12. Questions. * Is the Python ecosystem ready for the distutils removal? How many projects

[Python-Dev] Re: Supported make implementations

On 12/03/2022 06.27, Lincoln Auster wrote: Hi, When attempting to build and run doctests for cpython on FreeBSD, I got a vague error from the default BSD make. gmake, of course, ran fine. Is GNU make the only supported make implementation? If so, did I miss that in the devguide, or should that

[Python-Dev] Re: Defining tiered platform support

On 07/03/2022 18.02, Petr Viktorin wrote: Why the devguide? I view the list of platforms as important for public consumption as for the core dev team to know what to (not) accept PRs for. So, let's put it in the main docs? Yes, I guess the devguide is a weird place to check for this kind of

[Python-Dev] Re: Defining tiered platform support

On 04/03/2022 21.41, Brett Cannon wrote: Therefore I propose that we target the oldest manylinux standard accepted by PyPI, for which the operating system has not reached its EOL. At the moment this is manylinux2014, aka CentOS 2024 with EOL June 2024. We could also state that we

[Python-Dev] Re: Defining tiered platform support

Hi Brett, thanks for starting the discussion! Much appreciated. On 04/03/2022 00.30, Brett Cannon wrote: Tier 1 is the stuff we run CI against: latest Windows, latest macOS, Linux w/ the latest glibc (I don't know of a better way to define Linux support as I don't know if a per-distro list is

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

On 06/02/2022 15.08, Victor Stinner wrote: Hi, I propose to deprecate the urllib module in Python 3.11. It would emit a DeprecationWarning which warn users, so users should consider better alternatives like urllib3 or httpx: well known modules, better maintained, more secure, support HTTP/2

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

On 02/02/2022 09.19, dw-...@d-woods.co.uk wrote: Guido van Rossum wrote: My question for you is if you're willing to write up a list of things in CPython that you depend on. Or is this just something you're not willing to commit to? It would be nice to know which it is, just so the CPython team

[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python

On 01/02/2022 16.08, Victor Stinner wrote: -- I would prefer to introduce C API incompatible changes differently: first fix Cython, and *then* introduce the change. - (1) Propose a Cython PR and get it merged - (2) Wait until a new Cython version is released - (3) If possible, wait until numpy

[Python-Dev] Re: Dropping AC_C_CHAR_UNSIGNED from configure.ac?

On 24/01/2022 14.34, Miro Hrončok wrote: Hello Pythonistas. In (development branch of) Fedora, we have juts upgraded to GCC 12. It seems that the presence of AC_C_CHAR_UNSIGNED in Python's autotools files (configure.ac?) is causing the __CHAR_UNSIGNED__ symbol to be defined in pyconfig.h and

[Python-Dev] Re: [PSA] OpenSSL 3.0 support is preliminary and experimental

On 10/01/2022 17.01, Miro Hrončok wrote: On 09. 01. 22 19:39, Christian Heimes wrote: Hi, I would like to remind everybody that Python's support for OpenSSL 3.0 is preliminary [1]. Python compiles with OpenSSL 3.0.0 and simple code kinda works. However there are known performance regressions

[Python-Dev] Re: [PSA] OpenSSL 3.0 support is preliminary and experimental

On 11/01/2022 12.02, Antoine Pitrou wrote: Hi Christian, On Sun, 9 Jan 2022 19:39:06 +0100 Christian Heimes wrote: Hi, I would like to remind everybody that Python's support for OpenSSL 3.0 is preliminary [1]. Python compiles with OpenSSL 3.0.0 and simple code kinda works. However

[Python-Dev] [PSA] OpenSSL 3.0 support is preliminary and experimental

Hi, I would like to remind everybody that Python's support for OpenSSL 3.0 is preliminary [1]. Python compiles with OpenSSL 3.0.0 and simple code kinda works. However there are known performance regressions, missing features (e.g. usedforsecurity flag), and potential bugs cause by API

[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL

On 14/12/2021 19.19, Eric Snow wrote: A while back I concluded that neither approach would work for us. The approach I had taken would have significant cache performance penalties in a per-interpreter GIL world. The approach that modifies Py_INCREF() has a significant performance penalty due

[Python-Dev] Re: Python release announcement format

On 14/12/2021 11.56, Yann Droneaud wrote: Hi, I'm not familiar with the Python release process, but looking at the latest release https://www.python.org/downloads/release/python-3101/ we can see MD5 is still used ... which doesn't sound right in 2021 ... especially since we proved it's

[Python-Dev] Re: Explicit markers for special C-API situations

On 10/12/2021 03.08, Jim J. Jewett wrote: Christian Heimes wrote: On 09/12/2021 19.26, Petr Viktorin wrote: If the code is the authoritative source of truth, we need a proper parser to extract the information. ... unfortunately I don't trust it enough to let it define the API. Bugs

[Python-Dev] Re: Explicit markers for special C-API situations (re: Clarification regarding Stable ABI and _Py_*)

On 09/12/2021 19.26, Petr Viktorin wrote: I'll not get back to CPython until Tuesday, but I'll add a quick note for now. It's a bit blunt for lack of time; please don't be offended. If the code is the authoritative source of truth, we need a proper parser to extract the information. But we

[Python-Dev] Re: Clarification regarding Stable ABI and _Py_*

On 07/12/2021 19.28, Guido van Rossum wrote: I assume it would be insensitive to ask whether we could just get rid of the stable ABI altogether and focus on the limited API? Just tell everyone they have to rebuild binary wheels for every Python feature release. Presumably the deprecation of

[Python-Dev] Re: compiled python3.10 is unable to find _ssl

On 20/10/2021 09.43, Robin Becker wrote: On 19/10/2021 16:45, Christian Heimes wrote: We use the standard AX_CHECK_OPENSSL() m4 macro from autoconf-archive to detect OpenSSL. The macro uses pkg-config to detect OpenSSL. It doesn't check for specific version, though. We don't want to prevent

[Python-Dev] Re: compiled python3.10 is unable to find _ssl

On 19/10/2021 17.26, Robin Becker wrote: On 19/10/2021 11:21, Christian Heimes wrote: On 19/10/2021 11.57, Robin Becker wrote: .. For PEP 644 I added new instructions how to build Python 3.10 with custom OpenSSL builds. The instructions should work on all major Linux distributions

[Python-Dev] Re: compiled python3.10 is unable to find _ssl

On 19/10/2021 11.57, Robin Becker wrote: On 18/10/2021 18:50, Senthil Kumaran wrote: Your configure script did pick up openssl as the support version was not found. What is your operating system? Make sure you have supported version of ssl. Python requires openssl 1.1.1 or higher. ... I

[Python-Dev] Re: python3.10 compilation on OpenBSD: running into ssl issues

On 06/10/2021 09.06, Sandeep Gupta wrote: Tried with openssl. Some progress but no success.  The configure checks went through find. >configure:17536: checking for openssl/ssl.h in /home/kabira/DrivingRange//project_versa/Build >s/openssl-1.1.1l >configure:17543: result: yes

[Python-Dev] Re: python3.10 compilation on OpenBSD: running into ssl issues

On 05/10/2021 16.40, Sandeep Gupta wrote: Trying to compile python3.10 on openbsd 7.0 on Pi4. It seems to run into several openssl issue.  I have installed openssl as I couldn't find libreSSL in the package manager. Your installation is picking up header files from LibreSSL. Python 3.10

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

On 27/09/2021 16.32, Ronald Oussoren via Python-Dev wrote: On 26 Sep 2021, at 19:03, Christian Heimes <mailto:christ...@python.org>> wrote: On 26/09/2021 13.07, jack.jan...@cwi.nl <mailto:jack.jan...@cwi.nl> wrote: The problem with the stable ABI is that very few developers

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

On 26/09/2021 13.07, jack.jan...@cwi.nl wrote: The problem with the stable ABI is that very few developers are targeting it. I’m not sure why not, whether it has to do with incompleteness of the ABI, or with issues targeting it easily and your builds and then having pip/PyPI do the right

[Python-Dev] Re: Why list.sort() uses mergesort and not timsort?

On 06/06/2021 11.42, Marco Sulla wrote: > As title. Is it faster for inplace sorting, or simply the > implementation of list.sort() was done before the implementation of > timsort? list.sort() uses timsort. What makes you think that Python uses mergesort? Tim Peters invented timsort for Python

[Python-Dev] Re: [python-committers] IMPORTANT: Python 3.10b2 release blockers

On 25/05/2021 00.45, Pablo Galindo Salgado wrote: > Hi, > > Tomorrow is the scheduled release of Python 3.10 beta 2 but > unfortunately we have several release blockers: > > https://bugs.python.org/issue44043 : > 3.10 b1 armhf Bus Error in hashlib test:

[Python-Dev] Re: March Steering Council update.

On 18/05/2021 16.19, Guido van Rossum wrote: > There are a few mentions of Debian, but no explanation of what the issue > is about. Can you elaborate on that? Debian and Debian-based distros like Ubuntu are applying downstream packages and split CPython interpreter and stdlib into multiple

[Python-Dev] Re: PEP 644 Accepted -- Require OpenSSL 1.1.1 or newer

On 30/03/2021 13.46, Pablo Galindo Salgado wrote: > Hi Christian, > > Thank you for submitting PEP 644 (Require OpenSSL 1.1.1). After evaluating > the situation and discussing the PEP, the Steering Council is happy with > the PEP, > and hereby accepts it. The SC is of the opinion that this change

[Python-Dev] Re: How about using modern C++ in development of CPython ?

On 16/04/2021 19.14, redrad...@gmail.com wrote: > My personal stop of contributing in CPython is that it is written in pure C !! > I wrote code in both: pure C and C++, but I like writing code in C++, because > it simplifies things without losing perfomance There are plenty of Open Source

[Python-Dev] Re: How about using modern C++ in development of CPython ?

On 16/04/2021 19.39, Victor Stinner wrote: > A *fresh* build (after make clean) of CPython on my laptop (8 threads, > 4 CPU cores) takes 13 seconds using make -j10 and gcc -O0. A fresh > build in release mode (make -j10 and gcc -O3) takes 44 seconds on the > same laptop. $ make clean $ time make

[Python-Dev] Re: SC feedback: PEP 648 -- Extensible customizations of the interpreter at startup

On 30/03/2021 19.01, Barry Warsaw wrote: > Hello Mario, > > Thank you for your submission of PEP 648 (Extensible customizations of the > interpreter at startup). The Python Steering Council has reviewed the PEP > and before we can pronounce on it, we have some additional questions and >

[Python-Dev] OpenSSL 1.1.1k CVE fixes

Hi, OpenSSL released 1.1.1k today with two high severity CVEs, https://www.openssl.org/news/vulnerabilities.html The ssl module is not affected by CVE-2021-3450 in its default configuration. Python does not set X509_V_FLAG_X509_STRICT on SSLContext. Only applications that that use

[Python-Dev] Re: How about using modern C++ in development of CPython ?

On 25/03/2021 18.39, Antoine Pitrou wrote: > On Thu, 25 Mar 2021 20:22:55 +0300 > Ivan Pozdeev via Python-Dev wrote: >> On 24.03.2021 19:58, Antoine Pitrou wrote: >>> On Wed, 24 Mar 2021 19:45:49 +0300 >>> Ivan Pozdeev via Python-Dev wrote: How does C++ fare in binary compatibility? Last

[Python-Dev] Re: Steering Council update for February

On 11/03/2021 00.38, Mike Miller wrote: > > On 2021-03-10 13:45, David Mertz wrote: >> In contrast, the "master" used in version control directly borrows >> from so-called "master/slave network architecture." > > > It was shown upthread that this isn't the case.  Do you have more > accurate

[Python-Dev] Re: Steering Council update for February

On 10/03/2021 10.30, Antoine Pitrou wrote: > On Wed, 10 Mar 2021 10:30:43 +0900 > Inada Naoki wrote: >> On Wed, Mar 10, 2021 at 10:10 AM Ivan Pozdeev via Python-Dev >> wrote: >>> >>> On 10.03.2021 3:53, Chris Angelico wrote: On Wed, Mar 10, 2021 at 11:47 AM Damian Shaw wrote:

[Python-Dev] Re: Steering Council update for February

On 10/03/2021 01.53, Chris Angelico wrote: > On Wed, Mar 10, 2021 at 11:47 AM Damian Shaw > wrote: >> >>> Does 'master' confuse people? >> >> There's a general movement to replace language from common programming >> practises that derive from, or are associated with, the dehumanization of >>

[Python-Dev] Re: Need help to fix known Python security vulnerabilities

On 08/03/2021 22.02, Victor Stinner wrote: Thanks Victor! > == XML == > > Python XML parsers have at least two known vulnerabilities: "billion > laughs" and "quadratic blowup" which are documented: > https://docs.python.org/dev/library/xml.html#xml-vulnerabilities > > The third party

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On 24/02/2021 20.03, Christian Heimes wrote: > On 24/02/2021 19.17, Steve Dower wrote: >> On 2/24/2021 4:26 PM, Christian Heimes wrote: >>> On 24/02/2021 15.16, Random832 wrote: >>>> On Wed, Feb 24, 2021, at 06:27, Christian Heimes wrote: >>>>> Separate

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On 24/02/2021 19.17, Steve Dower wrote: > On 2/24/2021 4:26 PM, Christian Heimes wrote: >> On 24/02/2021 15.16, Random832 wrote: >>> On Wed, Feb 24, 2021, at 06:27, Christian Heimes wrote: >>>> Separate directories don't prevent clashes and system breakage. But >

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On 24/02/2021 15.16, Random832 wrote: > On Wed, Feb 24, 2021, at 06:27, Christian Heimes wrote: >> Separate directories don't prevent clashes and system breakage. But they >> provide an easy way to *recover* from a broken system. > > I think it could be turned into

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On 24/02/2021 11.52, Stéfane Fermigier wrote: > I love pipx and I'm glad it exists at this point because it make  > > The main issue is that each virtualenv takes space, lots of space. > > I have currently 57 apps installed via pipx on my laptop, and the 57 > environments take almost 1 GB

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

f Python, and the following >> statement stood out for me as shocking: >> >> Christian Heimes wrote: >>> Core dev and PyPA has spent a lot of effort in promoting venv because we >>> don't want users to break their operating system with sudo pip install. >> >&

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

On 21/02/2021 13.47, glaub...@debian.org wrote: > Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 platforms. > There is no separate configure guard. All platforms that Rust can build for, > are always enabled by default. No one in Rust keeps anyone from > cross-compiling code

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

On 21/02/2021 13.13, Victor Stinner wrote: > Hi, > > I propose to actively remove support for *legacy* platforms and > architectures which are not supported by Python according to PEP 11 > rules: hardware no longer sold and end-of-life operating systems. The > removal should be discussed on a

[Python-Dev] Re: Security releases of CPython

On 19/02/2021 23.22, Stestagg wrote: > The thing that stood out from this conversation, for me, is: Releases > are too hard, and there’s a risk of not having enough volunteers as a > result. > > How hard is it to fix that?  Actually it's easy to fix! The PSF needs needs sufficient money to hire

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

On 01/02/2021 17.39, M.-A. Lemburg wrote: >> Can you explain where wchar_t* type is appropriate and how two >> conversions is a performance bottleneck? > > If an extension has a wchar_t* string, it should be easy > to convert this in to a Python bytes object for use in Python. How much software

[Python-Dev] Re: Upcoming 3.7.10 and 3.6.13 Security Releases

On 20/01/2021 13.06, Miro Hrončok wrote: > On 10. 01. 21 21:15, Ned Deily wrote: >> We are planning to produce the next security-fix rollup releases for >> Python 3.7.x and 3.6.x on 2021-01-15. The most recent releases for >> these versions were on 2020-08-17.  There has not been a lot of >>

[Python-Dev] Re: Where is the SQLite module maintainer

On 27/12/2020 21.20, Erlend Aasland wrote: > Hi, everyone. > > I'm trying to find a reviewer for this trivial > PR: https://github.com/python/cpython/pull/20530 > > (The PR fixes /CheckTraceCallbackContent/ (in the sqlite3 test suite) > for SQLite

[Python-Dev] Re: Distro packagers: PEP 615 and the tzdata dependency

Fedora has plans to fix this > <https://src.fedoraproject.org/rpms/python3.10/pull-request/13>, and > Christian Heimes has opened a bug on the Ubuntu launchpad > <https://bugs.launchpad.net/ubuntu/+source/python3.9/+bug/1904271> for > this. I will figure out how bes

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

On 30/10/2020 08.58, Serhiy Storchaka wrote: > It would make life of Illumos and OpenIndiana developers much harder, > that can be seen hostile to open source community. It would make the > code of CPython more rigid, virtually Linux-only with Windows and MacOS > patches, and as a side effect can

[Python-Dev] Re: When to remove BytesWarning?

On 24/10/2020 05.19, Inada Naoki wrote: > Hi, all. > > To avoid BytesWarning, the compiler needs to do some hack when they > need to store bytes and str constants in one dict or set. > BytesWarning has maintenance costs. It is not huge, but significant. > > When can we remove it? My idea is: >

[Python-Dev] Re: Speeding up CPython

On 21/10/2020 20.55, Larry Hastings wrote: > On 10/21/20 5:58 AM, Petr Viktorin wrote: >> At the risk of going off topic: That's for GCC. As far as I know, MSVC >> uses something like __declspec( thread ). >> What are the options for generic C99 compilers, other than staying slow? > > > As a

[Python-Dev] Re: Speeding up CPython

On 21/10/2020 11.37, Steven D'Aprano wrote: > On Wed, Oct 21, 2020 at 09:06:58AM +0200, Christian Heimes wrote: >> On 21/10/2020 00.14, Steven D'Aprano wrote: >>> On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote: >>> >>>> What I don't see is w

[Python-Dev] Re: Speeding up CPython

On 21/10/2020 09.35, Paul Moore wrote: > On Wed, 21 Oct 2020 at 08:14, Christian Heimes wrote: >> >> On 21/10/2020 00.14, Steven D'Aprano wrote: >>> On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote: >>> >>>> What I don't see is wh

[Python-Dev] Re: Speeding up CPython

On 21/10/2020 00.14, Steven D'Aprano wrote: > On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote: > >> What I don't see is where the money's coming from. It's fine to ask, >> but will anyone come up with that sort of funding? > > I don't think Mark is asking for you or I to fund the

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

On 09/10/2020 15.48, Antoine Pitrou wrote: > On Fri, 9 Oct 2020 05:04:55 +0300 > Ivan Pozdeev via Python-Dev wrote: >> I don't see the point of requiring to "write an apology", especially *before >> a 12-month ban*. If they understand that their behavior is >> wrong, there's no need for a ban,

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

On 09/10/2020 04.04, Ivan Pozdeev via Python-Dev wrote: > I don't see the point of requiring to "write an apology", especially > *before a 12-month ban*. If they understand that their behavior is > wrong, there's no need for a ban, at least not such a long one; if they > don't, they clearly aren't

[Python-Dev] [OT] I'm unsubscribing from this tire fire (formerly known as python-dev)

Y'all, trigger warning: strong opinion The Urban Dictionary defines the term "tire fire": A horrifying mess, either literally or figuratively foul-smelling, that seems to last forever. The term describes my current view of python-dev perfectly. It has always been a problematic and mentally

[Python-Dev] Re: test_ssl.py hangs with SSL 1.1 built with no threads

On 27/04/2020 19.27, mig28sua...@hotmail.com wrote: > Hello! > > This is my first time posting to the group. > > I've been running builds of Python 3.7.x on CentOS Linux release 7.7 > (64bit/Intel Core 2 Duo) > and I ran into hangs with test_ssl.py when using latest SSL 1.1.1d sources. > >

[Python-Dev] Re: sqlite3 module and thread-safe SQLite library

On 18/12/2019 00.56, Gregory P. Smith wrote: > > On Tue, Dec 17, 2019 at 12:30 PM Kacvinsky, Tom > mailto:tom.kacvin...@vector.com>> wrote: > > We ran into an issue where having the SQLite library built with > -DSQLITE_THREADSAFE=0, > but then the sqlite3 module (really, the

[Python-Dev] Re: Documenting sorted/min/max prerequisites

On 14/12/2019 15.20, Serhiy Storchaka wrote: > 14.12.19 15:29, Steven D'Aprano пише: >> I might be misinterpreting the evidence, but sorting works on objects >> that define `__gt__` without `__lt__`. >> >> py> class A: >> ... def __init__(self, x): self.x = x >> ... def __gt__(self,

[Python-Dev] Re: Deprecating the "u" string literal prefix

On 03/12/2019 21.04, Ethan Furman wrote: > On 12/03/2019 09:31 AM, Guido van Rossum wrote: > >> I think it’s too soon to worry about this. I don’t see a reason to >> harass people who maintain code based that were just recently migrated. > > I'm happy to go with this, since my libraries still do

[Python-Dev] Re: Deprecating the "u" string literal prefix

On 03/12/2019 19.09, Barry Warsaw wrote: > On Dec 3, 2019, at 09:16, Serhiy Storchaka > wrote: >> >> The 'u" string literal prefix was removed in 3.0 and reintroduced >> in 3.3 to help writing the code compatible with Python 2 and 3 >> [1]. After the dead of Python 2.7 we will remove some

[Python-Dev] Re: Restricted Entry Point from PEP-551/578

On 21/11/2019 21.19, Jason Killen wrote: > I knew the audit hooks were new but didn't realize they were quite that > new.  I didn't mean to come across as pejorative asking if people cared > about this.  The fact that I had trouble finding more information made > me think this good stuff had been

[Python-Dev] Re: Restricted Entry Point from PEP-551/578

On 21/11/2019 18.27, Jason Killen wrote: > I sent in a couple of PRs, accepted and merged (Thanks!), lately that > switch to using io.open_code when appropriate.  In the process of making > those PRs I spent a bit of time reading the two related PEPs.  In > PEP-551 there's a suggestion that people

[Python-Dev] Re: urllib request HTTPS memory leak?

On 16/09/2019 23.37, V-ron P wrote: > Hello Python Dev, > > One of my HTTPS servers leaked over 8 GB of memory over the past week. > After troubleshooting the issue, I managed to narrow it down to the > minimal test case below: > >

[Python-Dev] Re: Docs: audit event table empty

On 09/07/2019 14.02, Julien Palard wrote: > Hi Christian, > >> the table with auditing events does not render on docs.python.org, >> https://docs.python.org/3.9/library/audit_events.html. Steve and I are >> going to present the auditing feature tomorrow at EuroPython. It would >> be helpful to

[Python-Dev] Docs: audit event table empty

Hi, the table with auditing events does not render on docs.python.org, https://docs.python.org/3.9/library/audit_events.html. Steve and I are going to present the auditing feature tomorrow at EuroPython. It would be helpful to have the table available. It works on Steve's and my local machine

[Python-Dev] Re: 3.7.4 final delayed [Was: Python 3.7.4rc1 (and 3.6.9rc1) cutoffs ahead, now set for 2019-06-17]

On 29/06/2019 21.53, Ned Deily wrote: > On Jun 6, 2019, at 01:43, Ned Deily wrote: >> >> https://discuss.python.org/t/python-3-7-4rc1-and-3-6-9rc1-cutoffs-ahead-now-set-for-2019-06-17/1824 >> [...] >> Following the rc1 cutoff, changes merged to the >> 3.7 branch will be released in 3.7.5 three

[Python-Dev] Re: EuroPython 2019 sprints

On 13/06/2019 18.28, Steve Dower wrote: > Hi all > > Just letting everyone know that I signed up any core devs who are going > to be at EuroPython to run sprints :) (including myself, since I'll be > there) > > Like PyCon US, the sprints at EuroPython will attract many first-time > contributors,

[Python-Dev] Re: python3 -bb and hash collisions

On 18/06/2019 18.32, Daniel Holth wrote: > set([u"foo", b"foo]) will error because the two kinds of string have the > same hash, and this causes a comparison. Is that correct? Yes, it will fail with -bb, because it turns comparison between str and bytes into an error. This can also happen with

Re: [Python-Dev] PEP 590: vectorcall without tp_call

On 29/05/2019 15.29, Petr Viktorin wrote: > On 5/29/19 2:25 PM, Jeroen Demeyer wrote: >> Hello, >> >> I have one implementation question about vectorcall which is not >> specified in PEP 590: what should happen if a type implements >> vectorcall (i.e. _Py_TPFLAGS_HAVE_VECTORCALL is set) but

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 23/05/2019 02.58, Steven D'Aprano wrote: > On Wed, May 22, 2019 at 01:31:18PM +0200, Christian Heimes wrote: >> On 22/05/2019 12.19, Steven D'Aprano wrote: >>> I don't think this PEP should become a document about "Why you should >>> use PAM". I appreciat

Re: [Python-Dev] PEP 594: update 1

On 22/05/2019 02.44, Brett Cannon wrote: > It also doesn't help that no one is listed in the experts index for the > module either.. Excellent point! The PEP now lists the presence / absence of experts. Christian ___ Python-Dev mailing list

[Python-Dev] PEP 594: discussion-to discuss.python.org

Please use https://discuss.python.org/t/pep-594-removing-dead-batteries-from-the-standard-library/1704 for feedback and discussion. Thank you, Christian ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 22/05/2019 06.59, Stephen J. Turnbull wrote: > Christian Heimes writes: > > > It's all open source. It's up to the Python community to adopt > > packages and provide them on PyPI. > > > > Python core will not maintain and distribute the packages. I'll &g

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 22/05/2019 12.19, Steven D'Aprano wrote: > I don't think this PEP should become a document about "Why you should > use PAM". I appreciate that from your perspective as a Red Hat security > guy, you want everyone to use best practices as you see them, but it > isn't Python's position to

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 22/05/2019 01.11, Glenn Linderman wrote: > On 5/21/2019 2:00 PM, Nathaniel Smith wrote: >> On Tue, May 21, 2019 at 10:43 AM Glenn Linderman >> wrote: >>> After maintaining my own version of http.server to fix or workaround some >>> of its deficiencies for some years, I discovered bottle.py.

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 22/05/2019 08.30, Giampaolo Rodola' wrote: > > > On Tue, 21 May 2019 at 04:30, Antoine Pitrou > wrote: > > > NNTP is still quite used (often through GMane, but probably not only) so > I'd question the removal of nntplib. > > > I concur nntplib should

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 22/05/2019 06.20, Arfrever Frehtes Taifersar Arahesis wrote: > 2019-05-21 00:06 UTC+02:00, Christian Heimes wrote: >> On 20/05/2019 23.27, Antoine Pitrou wrote: >>> Removing the crypt module would remove support for system-standard >>> password files. I don

Re: [Python-Dev] Python in next Windows 10 update

On 21/05/2019 22.30, Steve Dower wrote: > Hi all > > Just sharing this here because I think it's important for us to be aware of > it - I'm not trying to promote or sell anything here :) (Those who were at > the language summit have seen this already.) > > In the next Windows 10 update that

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 20.35, Guido van Rossum wrote: > On Tue, May 21, 2019 at 11:17 AM Christian Heimes <mailto:christ...@python.org>> wrote: > > I'm already facing opposition for modules that are less controversial and > useful than http.server, too. > > >

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 20.18, Giampaolo Rodola' wrote: > No, the statement is correct. I may have to explain this even further. > > The approach in pyftpdlib is the wrong and IMO deserves a CVE. The > crypt() + spwd() approach is flawed on multiple levels. For example it > bypasses account

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 16.46, Guido van Rossum wrote: > +1. Let's keep colorsys then. I let colorsys off the hock, https://github.com/python/peps/pull/1070 Thanks for your feedback, Walter and Petr! Christian ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 18.29, Glenn Linderman wrote: > On 5/20/2019 2:20 PM, Christian Heimes wrote: >> On 20/05/2019 23.12, Andrew Svetlov wrote: >>> socketserver.py is also questionable >> I briefly though about the module, but didn't consider it for removal. The >&

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 18.08, Giampaolo Rodola' wrote: > > > On Tue, 21 May 2019 at 21:13, Christian Heimes <mailto:christ...@python.org>> wrote: > > crypt > ~ > > The `crypt <https://docs.python.org/3/library/crypt.html>`_ module > implements

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 18.08, Giampaolo Rodola' wrote: > > > On Tue, 21 May 2019 at 21:13, Christian Heimes <mailto:christ...@python.org>> wrote: > > crypt > ~ > > The `crypt <https://docs.python.org/3/library/crypt.html>`_ module > implements

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 17.31, Antoine Pitrou wrote: > > As I said, if the main annoyance with nntplib is the sporadic test > failures, then the relevant tests can be disabled on CI. > > NNTP itself is still used, even if less and less. I don't like the idea to drop a third of the test cases for nntplib

Re: [Python-Dev] PEP 594: update 1

On 21/05/2019 17.35, Guido van Rossum wrote: > OK, sounds like nntplib can stay — this time.  > > On Tue, May 21, 2019 at 08:33 Antoine Pitrou > wrote: > > > As I said, if the main annoyance with nntplib is the sporadic test > failures, then the relevant

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 15.54, Victor Stinner wrote: > IMHO we should simply acknowledge this fact by mentioning it in the > PEP. We are aware that "pip install" is not always a valid option, but > we decided anyway to deprecate/remove modules because <...>. I like the idea. Could you create an issue or

[Python-Dev] PEP 594: update 1

library Author: Christian Heimes Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 20-May-2019 Post-History: 21-May-2019 Abstract This PEP proposed a list of standard library modules to be removed from the standard library. The modules are mostly historic data formats

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 15.01, Steven D'Aprano wrote: > Christian, I'm glad that you are privileged enough to find it simple and > straight forward to download and install, but for many Python users, it > is not so simple or straight forward. > > Many Python users don't have the privilege of being able

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 14.06, Anders Munch wrote: > Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan...@python.org] På > vegne af Christian Heimes >> * The removed modules will be available through PyPI. > > Will they? That's not the impression I got from the PEP. It's all op

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 13.50, Victor Stinner wrote: > Hi Christian, > > I dislike the PEP 594 title: "Removing dead batteries from the > standard library". A module is never "dead", there are always users, > even if there are less than 5 of them. I'm open for suggestions for a better title. > Extract of

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 13.08, André Malo wrote: > On Montag, 20. Mai 2019 23:27:49 CEST Antoine Pitrou wrote: >> NNTP is still quite used (often through GMane, but probably not only) so >> I'd question the removal of nntplib. >> >> cgitb used to be used by some Web frameworks in order to format >>

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 21/05/2019 12.19, Giampaolo Rodola' wrote: > I find this one useful and would be a bit sad to see it go. FWIW I use it in > pyftpdlib and I suppose there are other apps out there relying on UNIX > password db for authentication. The fact that it’s a C module is also an > incentive to leave

  1   2   3   4   5   6   7   8   9   10   >