[Python-Dev] Re: PEP 448 review

Wow, we are now getting Canadian-specific spam! Since the volume on this mailing list is so low, should we change everyone to be moderated to start and then remove that after they have posted appropriately? Or did this get through by accident? On Wed, Mar 29, 2023 at 12:19 PM wrote: > It seems

[Python-Dev] Re: please consider changing --enable-unicode default to ucs4

Python no longer has `--enable-unicode` as part of `./configure`. On Tue, Mar 14, 2023 at 9:26 AM Jonathan Benson via Python-Dev < python-dev@python.org> wrote: > > > Sent from my iPhone > ___ > Python-Dev mailing list -- python-dev@python.org > To

[Python-Dev] Re: Contributing the Pyston jit?

FYI you will probably get more engagement if you posted this to discuss.python.org . On Thu, Feb 23, 2023, 10:18 Kevin Modzelewski wrote: > Hello all, we on the Pyston team would like to propose the contribution of > our JIT >

[Python-Dev] Re: Contributing the Pyston jit?

On Thu, Feb 23, 2023, 11:34 Wes Turner wrote: > Please consider colesbury/nogil in rebasing? > https://github.com/colesbury/nogil > It's very premature for anyone to concern themselves with Sam's nogil work when it comes to their own work as PEP 703 has not been sent to the SC (let alone been

[Python-Dev] Re: Python Launcher not Installed on Windows Machine

How did you install Python? If you got it from the Microsoft Store I believe the Python Launcher is not included. On Tue, Dec 13, 2022 at 7:20 PM Margo Hoover wrote: > Dear Jonathan and Brian, > > I have python and pip installed on my Windows machine. However, I do not > seem to have the python

[Python-Dev] Re: Switching to Discourse

On Fri, Dec 2, 2022 at 8:17 AM Baptiste Carvello < devel2...@baptiste-carvello.net> wrote: > Le 02/12/2022 à 10:09, Gregory P. Smith a écrit : > > > > On Thu, Dec 1, 2022 at 8:37 AM Victor Stinner > > wrote: > > > > > > Should we *close* the python-dev mailing

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

On Tue, Nov 29, 2022 at 12:58 PM Yoni Lavi wrote: > It does make your argument invalid though, It makes that single sentence invalid, but the rest of my points still hold, e.g. the language makes no guarantee about hash consistency between executions, set order is not guaranteed, etc. are all

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

On Mon, Nov 28, 2022 at 5:38 PM Steven D'Aprano wrote: > On Mon, Nov 28, 2022 at 11:13:34PM +, Oscar Benjamin wrote: > > On Mon, 28 Nov 2022 at 22:56, Brett Cannon wrote: > > > > That's actually by design. Sets are not meant to be deterministic > > > concep

[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant

On Sun, Nov 27, 2022 at 11:36 AM Yoni Lavi wrote: > I wrote a doc stating my case here: > > https://docs.google.com/document/d/1et5x5HckTJhUQsz2lcC1avQrgDufXFnHMin7GlI5XPI/edit# > > Briefly, > > 1. The main motivation for it is to allow users to get a predictable > result on a given input (for

[Python-Dev] Re: problem with Distributed File System Replication and Namespacing and different versions of Python 3

On Fri, Oct 21, 2022 at 11:11 AM Juan Cristóbal Quesada < rainonthescarecrowhumanwhe...@gmail.com> wrote: > I guess my simplified question would be: > > ¿how does Python 3 versions manage Distributed File Systems and in > particular Windows' DFS? > In no specific way. We typically ask the OS to

[Python-Dev] Re: problem with Distributed File System Replication and Namespacing and different versions of Python 3

Import is implementing in Python itself via importlib, so you could try walking through the code with a debugger to see where the difference may be (I personally can't think of anything obvious that changed in importlib between 3.9 and 3.10 that would affect this). On Thu, Oct 20, 2022 at 11:36

[Python-Dev] Re: Moving to Discourse

On Thu, Sep 22, 2022 at 12:41 AM Baptiste Carvello < devel2...@baptiste-carvello.net> wrote: > Hello, > > Le 21/09/2022 à 13:14, Petr Viktorin a écrit : > > On 21. 09. 22 10:17, Baptiste Carvello wrote: > >> > >> * mailing-list mode: there needs to be a *standardized* set of filters > >> to

[Python-Dev] Re: Switching to Discourse

On Fri, Jul 22, 2022 at 3:45 AM Samuel Colvin wrote: > Reading this thread and thinking about discuss.python.org/Discourse - I'm > surprised no one is advocating github discussions > . > I think it's because discuss.python.org is what we decided to try

[Python-Dev] Re: Switching to Discourse

On Thu, Jul 21, 2022 at 10:34 AM Skip Montanaro wrote: > > No, Discord is a different thing; it does text and voice communication > > channels in real-time. If you're familiar with Slack, it's broadly > > similar in purpose. > > Thanks (and to the others who replied). FYI this multiple

[Python-Dev] Do not harass other mailing list subscribers privately

The SC has been notified of at least one instance of someone subscribed to this list harassing another subscriber privately. We wanted to remind folks that we expect people to behave reasonably towards each other, else people risk losing access to this mailing list and other places where Python is

[Python-Dev] Re: compiling errors, SSL

On Tue, Jul 19, 2022 at 2:17 PM Kevin T via Python-Dev < python-dev@python.org> wrote: > I have built this on systems at work, that are populated by CAD guys who > have developed a good set of libraries to maintain in a linux > distribution. Went without a hitch. > > I am trying to build this at

[Python-Dev] Re: New `python` Organization Repository Policy

On Fri, Jul 15, 2022 at 4:54 AM Joannah Nanjekye wrote: > I understand that the steering council decides new repositories that can > be added to the Python organization but as a committer, it is good courtesy > that public decisions are discussed first on committer channels because > this

[Python-Dev] Re: Method __func__ objects are unpicklable

I believe a lot of people use https://pypi.org/project/cloudpickle/ thanks to its support for pickling functions. On Fri, Jun 10, 2022 at 4:56 AM haael wrote: > > > During some sophisticated pickling I noticed that method `__func__` > objects are unpicklable, because they share the name with

[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

instability risk they were willing to take by having CI have an allowlist/blocklist of Python header files. -Brett > > Modifying preprocessor definitions for different Python versions, or > having to set them before knowing what version is being used, seems more > complicated. >

[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

We discussed having leading underscores for this API tier, and it was decided that a leading underscore was preferred. This did start a discussion, though, about whether we should control API access/opt-in via `#include` by having `.h` files that convey what API the user is opting into, or use

[Python-Dev] Re: Summary of Python tracker Issues

Can we shut this down or unsubscribe the weekly email? On Fri, May 13, 2022 at 11:13 AM Python tracker wrote: > > ACTIVITY SUMMARY (2022-05-06 - 2022-05-13) > Python tracker at https://bugs.python.org/ > > To view or respond to any of the issues listed below, click on the issue. > Do NOT

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

On Tue, May 10, 2022 at 10:23 AM Guido van Rossum wrote: > Shouldn't we wean our internal tools off this obsolete version of > distutils too, rather than just move it around? > I think so. We technically have a year to get this done, so if we can't do that then I'm afraid we have much bigger

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

On Tue, May 10, 2022 at 12:59 AM 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

[Python-Dev] Re: Can I ask a real dumb procedural question about GitHub email?

On Wed, May 4, 2022 at 11:26 AM Skip Montanaro wrote: > I subscribe to the python/cpython stuff on GitHub. I find it basically > impossible to follow because of the volume. I realize there are > probably plenty of extra changes going in based on the recent language > summit (and maybe some

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

On Tue, Apr 26, 2022 at 2:50 AM Victor Stinner wrote: > Hi, > > There are 4 main ways to run Python: > > (1) python -m module [...] > (2) python script.py [...] > (3) python -c code [...] > (4) python [...] > > (1) and (2) insert the directory of the module/script at sys.path[0]. > (3) and (4)

[Python-Dev] Re: Proposal to deprecate mailcap

After talking about this in the SC today, we agreed to deprecate mailcap under the auspices of PEP 594: https://github.com/python/peps/commit/701999a91dc5f976c00d5bde1510226ebd9c7822 . On Thu, Apr 14, 2022 at 11:44 AM Brett Cannon wrote: > A CVE has been opened against mailcap (see >

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On Sat, Apr 23, 2022 at 2:39 PM Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > UGH! > I understand you don't like the proposal, but do please try to keep it civil. It's totally okay to say you don't like something, but I don't think anyone would take kindly to someone coming up to

[Python-Dev] Re: Python multithreading without the GIL

On Sat, Apr 23, 2022 at 8:31 AM wrote: > Hello all, > > I am very excited about a future multithreaded Python. I managed to > postpone some rewrites in the company I work for Rust/Go, precisely because > of the potential to have a Python solution in the medium term. > > I was wondering. Is Sam

[Python-Dev] Re: GSOC

On Tue, Apr 19, 2022 at 7:14 AM Jean Abou Samra wrote: > Hi, > > Le 19/04/2022 à 01:56, faresbaso...@gmail.com a écrit : > > i want to contribute in mailman which is a sub-org under python software > > > Where do you see this? I can't find it under github.com/python. > The repository seems to be

[Python-Dev] Proposal to deprecate mailcap

A CVE has been opened against mailcap (see https://github.com/python/cpython/issues/68966 for details). I'm not aware of anyone trying to maintain the module and Victor did a search online and didn't find any use of the module in the top 5000 projects on PyPI (see the issue). The module is also

[Python-Dev] Re: Declarative imports

On Sun, Apr 10, 2022 at 2:39 AM Daniel Pope wrote: > On Fri, 8 Apr 2022, 17:44 Guido van Rossum, wrote: > >> The interesting idea here seems to make "lazy imports" easier to >> implement by making them explicit in the code. So far, most lazy import >> frameworks for Python have done hacks with

[Python-Dev] Re: Importing a submodule doesn't always set an attribute on its parent

On Sat, Apr 9, 2022 at 1:53 PM dfremont--- via Python-Dev < python-dev@python.org> wrote: > Thanks, Brett. I understand why the behavior happens, I just don't > understand the decision to implement imports this way. Since there's no > warning in the documentation that removing items from

[Python-Dev] Re: Importing a submodule doesn't always set an attribute on its parent

On Fri, Apr 8, 2022 at 4:38 PM dfremont--- via Python-Dev < python-dev@python.org> wrote: > Hello, > > I came across what seems like either a bug in the import system or a gap > in its documentation, so I'd like to run it by folks here to see if I > should submit a bug report. If there's

[Python-Dev] Re: About PEPs being discussed on Discourse

On Thu, Apr 7, 2022 at 7:33 PM Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > Gregory P. Smith writes: > > > We feel it too. We've been finding Discourse more useful from a > community > > moderation and thread management point of view as well as offering > markdown > > text and

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Wed, Mar 30, 2022 at 4:53 AM Barney Gale wrote: > On Wed, 30 Mar 2022 at 12:20, Antoine Pitrou wrote: > >> On Wed, 30 Mar 2022 12:03:58 +0100 >> Steve Dower wrote: >> > On 30Mar2022 1124, Barney Gale wrote: >> > > I'd like to become a maintainer for the pathlib module, if possible. >> I >>

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Tue, Mar 29, 2022 at 8:58 AM Ronald Oussoren wrote: > > > On 29 Mar 2022, at 00:34, Brett Cannon wrote: > > > > On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker > wrote: > >> On Mon, Mar 28, 2022 at 11:29 AM Paul Moore wrote: >> >>> To b

[Python-Dev] Re: Enhancing generic type documentation in the standard library

On Mon, Mar 28, 2022 at 3:58 PM Luciano Ramalho wrote: > On Wed, Mar 23, 2022 at 5:01 PM Brett Cannon wrote: > > The SC somewhat agrees!  See > https://mail.python.org/archives/list/typing-...@python.org/thread/TVMQJXOJFOYFPDMQDFG6G4B6J3MLRYKB/ > where we have asked for at

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker wrote: > On Mon, Mar 28, 2022 at 11:29 AM Paul Moore wrote: > >> To be honest, I feel like I'm just reiterating stuff I've said before >> here, and I think the same is true of the points I'm responding to > > ... > >> (I'm not *against*

[Python-Dev] Re: Enhancing generic type documentation in the standard library

On Wed, Mar 23, 2022 at 11:03 AM Luciano Ramalho wrote: > Hello, everyone! > > I believe our documentation about types needs another overhaul. > The SC somewhat agrees!  See https://mail.python.org/archives/list/typing-...@python.org/thread/TVMQJXOJFOYFPDMQDFG6G4B6J3MLRYKB/ where we have asked

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

On Wed, Mar 23, 2022 at 2:48 AM Petr Viktorin wrote: > On 22. 03. 22 19:07, Victor Stinner wrote: > > Hi, > > > > I proposed two PRs to move the private C API (Include/cpython/) of PEP > > 523 "Adding a frame evaluation API to CPython" to the internal C API > > (Include/internals/): > > > > *

[Python-Dev] Gathering edge cases around type annotation PEPs

I created https://discuss.python.org/t/finding-edge-cases-for-peps-484-463-and-649-type-annotations/14314 on behalf of the SC to help gather edge cases where the various approaches that PEPs have proposed will fail. Our hope is to get an overall picture of the trade-offs the various PEPs ask us to

[Python-Dev] Re: Defining tiered platform support

On Mon, Mar 14, 2022 at 11:18 PM Larry Hastings wrote: > > On 3/14/22 20:31, Brett Cannon wrote: > > > > On Fri, Mar 11, 2022 at 5:17 PM Victor Stinner > wrote: > >> It would be great to have the list of supported platforms per Python >> version! >>

[Python-Dev] Re: Defining tiered platform support

On Fri, Mar 11, 2022 at 5:17 PM Victor Stinner wrote: > It would be great to have the list of supported platforms per Python > version! > I could see the table in PEP 11 being copied into the release PEPs. > > Maybe supporting new platforms and dropping support for a platform > should be

[Python-Dev] Re: Defining tiered platform support

On Mon, Mar 7, 2022 at 11:05 AM Christian Heimes wrote: > 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

[Python-Dev] Re: Defining tiered platform support

On Mon, Mar 7, 2022 at 11:01 AM Christian Heimes wrote: > 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 > >

[Python-Dev] Re: Defining tiered platform support

On Fri, Mar 4, 2022 at 1:44 AM Petr Viktorin wrote: > On 04. 03. 22 0:30, Brett Cannon wrote: > > Do we officially support NetBSD? Do you know how to find out if we do? > > You might think to look at > > https://www.python.org/dev/peps/pep-0011/#supporting-platforms > &

[Python-Dev] Re: Defining tiered platform support

On Fri, Mar 4, 2022 at 1:32 AM Ronald Oussoren wrote: > > > On 4 Mar 2022, at 00:30, Brett Cannon wrote: > > Do we officially support NetBSD? Do you know how to find out if we do? You > might think to look at > https://www.python.org/dev/peps/pep-0011/#supporting-platfo

[Python-Dev] Re: Defining tiered platform support

On Fri, Mar 4, 2022 at 12:48 AM Christian Heimes wrote: > 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

[Python-Dev] Defining tiered platform support

Do we officially support NetBSD? Do you know how to find out if we do? You might think to look at https://www.python.org/dev/peps/pep-0011/#supporting-platforms , but that just loosely defines the criteria and it still doesn't list the actual platforms we support. (BTW I don't know if we do

[Python-Dev] Re: Test error

You might want to try asking your question at https://mail.python.org/mailman3/lists/core-mentorship.python.org/ which is specifically set up to help people. But in general, all the tests are passing for folks. You will need to run those tests individually to see why they are failing for you. On

[Python-Dev] Re: October/November/December Steering Council update

On Tue, Mar 1, 2022 at 9:00 AM Joannah Nanjekye wrote: > > Steering Council did a one hour Q recorded session with Visionary > sponsor, Bloomberg. > > Is it possible to access this recording for transparency purposes or is > it confidential? > We can ask, but I vaguely remember the folks at

[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 2)

On Wed, Feb 23, 2022 at 8:19 AM Petr Viktorin wrote: > On 23. 02. 22 2:46, Eric Snow wrote: > > [SNIP] > > > So it seems like the bar should be pretty low for this one (assuming > > we get the performance penalty low enough). If it were some massive > > or broadly impactful (or even clearly

[Python-Dev] Re: Request for feedback: pathlib.AbstractPath prototype

On Thu, Feb 10, 2022 at 2:15 PM Ethan Furman wrote: > On 2/10/22 1:45 PM, Brett Cannon wrote: > > > Protocols would let folks rely on a common Path object API w/o having > to require the object > > come from pathlib itself or explicitly subclass something (which I

[Python-Dev] Re: Request for feedback: pathlib.AbstractPath prototype

rett > > On Wed, 9 Feb 2022 at 19:02, Brett Cannon wrote: > >> One thing to discuss (and which has been brought up on the PR), is >> whether this should be an ABC to force people to explicitly raise >> `NotImplementedError`? >> >> The next question is

[Python-Dev] Re: Request for feedback: pathlib.AbstractPath prototype

One thing to discuss (and which has been brought up on the PR), is whether this should be an ABC to force people to explicitly raise `NotImplementedError`? The next question is whether any of this should be a (very wide) protocol instead of an ABC? On Wed, Feb 9, 2022 at 7:05 AM Barney Gale

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

On Tue, Feb 8, 2022 at 10:20 PM Steven D'Aprano wrote: > On Tue, Feb 08, 2022 at 05:48:46PM -0800, Gregory P. Smith wrote: > > On Tue, Feb 8, 2022 at 2:41 PM Steven D'Aprano > wrote: > > > > If the answer to those questions are Yes, that rules out using Unums, > > > posits, sigmoid numbers etc

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

On Wed, Feb 9, 2022 at 4:19 AM Petr Viktorin wrote: > > > On 09. 02. 22 4:39, h.vetin...@gmx.com wrote: > >> Maybe a more practical approach would be to use C99 "except of > > features not supported by MSVC of Visual Studio 2019"? > > > > This could be formulated in a more neutral way by saying

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

On Mon, Feb 7, 2022 at 5:51 PM Jim J. Jewett wrote: > There are problems with urllib. With hindsight, it would have been nice > to do a few things differently. But that doesn't make migrating away from > it any easier. > > This thread has mentioned several "better" alternatives -- but with the

[Python-Dev] Re: Steering Council reply to PEP 670 -- Convert macros to functions in the Python C API

On Tue, Feb 8, 2022 at 8:30 AM Victor Stinner wrote: > Hi Petr, > > Thanks for the SC review, it's very helpful! I know that it's a big PEP :-) > > On Tue, Feb 8, 2022 at 11:33 AM Petr Viktorin wrote: > > *All other things being equal, static inline functions are better than > > macros.* > >

[Python-Dev] Re: RFC on PEP 675: Arbitrary Literal Strings

On Mon, Feb 7, 2022 at 4:59 PM S Pradeep Kumar wrote: > On Mon, Feb 7, 2022 at 3:55 PM Brett Cannon wrote: > >> Can I suggest adding a "Specification" section (see >> https://www.python.org/dev/peps/pep-0012/#suggested-sections for the >> suggested sections to

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

On Mon, Feb 7, 2022 at 9:12 AM Victor Stinner wrote: > Hi, > > I made a change to require C99 "NAN" constant and I'm was > asked to update the PEP 7 to clarify the C subset is needed to build > Python 3.11. > > Python 3.6 requires a subset of the C99 standard to build defined by the > PEP 7: >

[Python-Dev] Re: RFC on PEP 675: Arbitrary Literal Strings

Can I suggest adding a "Specification" section (see https://www.python.org/dev/peps/pep-0012/#suggested-sections for the suggested sections to have in a PEP)? When you first pull up the PEP it goes from "Rationale" to "Valid Locations for LiteralString". As a reader that doesn't point me at a

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

On Mon, Feb 7, 2022 at 4:56 AM Steve Dower wrote: > On 2/6/2022 4:44 PM, Christian Heimes wrote: > > If I had the power and time, then I would replace urllib with a simpler, > > reduced HTTP client that uses platform's HTTP library under the hood > > (WinHTTP on Windows, NSURLSession (?) on

[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode

On Mon, Feb 7, 2022 at 8:59 AM Victor Stinner wrote: > On Mon, Feb 7, 2022 at 5:48 PM Guido van Rossum wrote: > > So you're proposing to completely get rid of those three? > > I don't propose to remove them, but only call them if Python is built > in debug mode. Or remove them from the release

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

On Mon, Feb 7, 2022 at 12:31 PM Gregory P. Smith wrote: > > > On Mon, Feb 7, 2022 at 11:06 AM Victor Stinner > wrote: > >> Hi Mark, >> >> Aha, good, you posted an email to python-dev, good :-) Last days, I >> was trying to collect more data about this topic, especially find >> platforms which

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

On Mon, Feb 7, 2022 at 11:02 AM Victor Stinner wrote: > Hi Mark, > > Aha, good, you posted an email to python-dev, good :-) Last days, I > was trying to collect more data about this topic, especially find > platforms which *don't* support IEEE 754, before posting to > python-dev. > > Nowadays,

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On Thu, Feb 3, 2022 at 3:53 PM Eric V. Smith wrote: > On 2/3/2022 12:15 PM, Victor Stinner wrote: > > I'm working bottom-to-top: prepare PyObject and PyVarObject to become > > opaque, *and* top-to-bottom: prepare subclasses (structures > > "inheriting" from PyObject and PyVarObject) to become

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

On Thu, Feb 3, 2022 at 6:31 AM Victor Stinner wrote: > On Wed, Feb 2, 2022 at 11:43 PM Eric Snow > wrote: > > My plan is to replace our use of _Py_IDENTIFIER() with statically > > initialized string objects (as fields under _PyRuntimeState). That > > involves the following: > > > > * add a

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

On Thu, Feb 3, 2022 at 6:37 AM Victor Stinner wrote: > By the way, Argument Clinic now produces way faster calling > conventions than hand-written METH_VARARGS with PyArg_ParseTuple(). It > would be make this tool available to 3rd party projects. > > Either extract it and put it on PyPI, but it

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On Thu, Feb 3, 2022 at 9:27 AM Victor Stinner wrote: > Hi Guido, > [SNIP] > > On Thu, Feb 3, 2022 at 1:40 AM Guido van Rossum wrote: > > [SNIP] > > > > Maybe we need to help there. For example IIRC conda-forge will build > conda packages -- maybe we should offer a service like that for

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

On Tue, Jan 18, 2022 at 9:43 AM Richard Damon wrote: > > > On Jan 18, 2022, at 11:34 AM, Guido van Rossum wrote: > >  > At best it shows that deprecations are complicated no matter how well you > plan them. I remember that "noisy by default" deprecation warnings were > widely despised. > > On

[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring

On Tue, Jan 11, 2022 at 10:40 AM Gregory P. Smith wrote: > > On Tue, Jan 11, 2022 at 10:29 AM Guido van Rossum > wrote: > >> I personally think F-strings should not be usable as docstrings. If you >> want a dynamically calculated docstring you should assign it dynamically, >> not smuggle it in

[Python-Dev] Re: Function Prototypes

On Thu, Dec 23, 2021 at 5:13 PM Guido van Rossum wrote: > On Thu, Dec 23, 2021 at 3:24 PM Steven D'Aprano > wrote: > >> On Thu, Dec 23, 2021 at 02:09:50PM -0800, Guido van Rossum wrote: >> >> > Without decorator too (that was Lukasz’ idea). Why bother with the >> > decorator (*if* we were to go

[Python-Dev] Re: RFC on Callable Syntax PEP

As someone with use of this, would you find this useful (i.e. +1, +0)? Serhiy already said "no" in another thread. On Mon, Dec 20, 2021 at 4:38 AM Andrew Svetlov wrote: > Perhaps Serhiy did more accurate counting, my estimate is very rough. > > On Mon, Dec 20, 2021 at 2:15 PM Serhiy Storchaka

[Python-Dev] Re: RFC on Callable Syntax PEP

On Mon, Dec 20, 2021 at 3:44 AM Mark Shannon wrote: > Hi, > > Why not make Callable usable as a function decorator? > > > > The motivating example in the PEP is this: > > > def flat_map( > l: list[int], > func: Callable[[int], list[int]] > ) -> list[int]: > > > > Since, as

[Python-Dev] Re: RFC on Callable Syntax PEP

On Sun, Dec 19, 2021 at 8:26 PM Christopher Barker wrote: > > On 12/18/2021 3:13 PM, Batuhan Taskaya wrote: >> >> > tl;dr: I find it very troubling that we are going on a path where need >> > to increase the language complexity (syntax) only in the cause >> > 'easier' typing. > > > Which brings

[Python-Dev] Re: The python command help is too long

On Sat, Dec 18, 2021 at 4:00 PM Guido van Rossum wrote: > On Sat, Dec 18, 2021 at 2:16 PM Serhiy Storchaka > wrote: > >> The output of "python -h" is 104 lines long now. It was only 51 lines in >> 3.6. 35% of it is about the -X option, and 30% about environment >> variables. Also some lines in

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

On Tue, Dec 14, 2021 at 10:23 AM Eric Snow wrote: > Most of the work toward interpreter isolation and a per-interpreter > GIL involves moving static global variables to _PyRuntimeState or > PyInterpreterState (or module state). Through the effort of quite a > few people, we've made good

[Python-Dev] Re: subinterpreters and their possible impact on large extension projects

On Tue, Dec 14, 2021 at 9:41 AM Eric Snow wrote: > One of the open questions relative to subinterpreters is: how to > reduce the amount of work required for extension modules to support > them? Thanks to Petr Viktorin for a lot of work he's done in this > area (e.g. PEP 489)! Extensions also

[Python-Dev] PEP template file now available

I just pushed an update to PEP 12 which includes a complete PEP template file. You can see the file at https://github.com/python/peps/blob/main/pep-0012/pep-.rst and it is also embedded in PEP 12 at https://python.github.io/peps/pep-0012/#template (it will hit the official URL eventually).

[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)

On Wed, Dec 1, 2021 at 10:40 PM Christopher Barker wrote: > I know this isn't really the place for this conversation, but: > > >> which is what `os.PathLike` represents, hence why `str` isn't covered by >> it); >> > > wait, what? It seems so clear to me that "PathLike" (as a type specifier) >

[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)

On Tue, Nov 30, 2021 at 1:34 PM Paul Moore wrote: > On Tue, 30 Nov 2021 at 19:07, Brett Cannon wrote: > > > > On Tue, Nov 30, 2021 at 9:09 AM Steven D'Aprano > wrote: > >> > >> On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote: > >> > &

[Python-Dev] Expectations of typing (was: The current state of typing PEPs)

On Tue, Nov 30, 2021 at 9:09 AM Steven D'Aprano wrote: > On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote: > > > And to be clear, it's often very non-obvious how to annotate something > > - in https://github.com/pfmoore/editables I basically gave up because > > I couldn't work out how

[Python-Dev] Re: Please be careful about changing PEPs post-submission to the SC

is helpful to let us know to simply halt thinking and discussing the PEP. > > On Thu, Nov 18, 2021 at 12:04 PM Brett Cannon wrote: > >> This is a personal plea (i.e. not coming from the SC at all), but in the >> last month we have had PEPs changed twice post-submission to the

[Python-Dev] Please be careful about changing PEPs post-submission to the SC

This is a personal plea (i.e. not coming from the SC at all), but in the last month we have had PEPs changed twice post-submission to the SC. That's a big time sink as we take multiple meetings to discuss a PEP and having things change underneath us causes us to have to re-evaluate our discussions

[Python-Dev] Re: SC Acceptance: PEP 646 -- Variadic Generics

I put the PEP back on our agenda to discuss this. On Wed, Nov 17, 2021 at 2:40 PM Guido van Rossum wrote: > Hi Barry, > > That's fantastic news! > > Somewhat embarrassingly, on typing-sig we're still discussing one or two > final tweaks. In particular, the PEP as accepted forbids a certain >

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On Tue, Nov 16, 2021 at 4:46 AM Petr Viktorin wrote: > On 16. 11. 21 1:11, Brett Cannon wrote: > > > > > > On Sun, Nov 14, 2021 at 3:01 PM Victor Stinner > <mailto:vstin...@python.org>> wrote: > > > > On Sun, Nov 14, 2021 at 6:34 PM Eric V. Sm

[Python-Dev] Re: portable venv

On Tue, Nov 16, 2021 at 8:08 AM Tamás Ozsváth wrote: > Hi All, > I tried to compose a protable virtualEnvironment using Python. I aready > found a solution which already works but still not stable. > So by creating venv in conventional way, I additionally copy the Python > executable and related

[Python-Dev] Re: Remove asyncore, asynchat and smtpd modules

On Tue, Nov 16, 2021 at 3:05 AM Petr Viktorin wrote: > On 12. 11. 21 13:09, Victor Stinner wrote: > >>> It was decided to start deprecating the asyncore, asynchat and smtpd > >>> modules in Python 3.6 released in 2016, 5 years ago. Python 3.10 emits > >>> DeprecationWarning. > >> > >> Wait, only

[Python-Dev] Re: Remove asyncore, asynchat and smtpd modules

On Fri, Nov 12, 2021 at 4:16 AM Victor Stinner wrote: > > > It was decided to start deprecating the asyncore, asynchat and smtpd > > > modules in Python 3.6 released in 2016, 5 years ago. Python 3.10 emits > > > DeprecationWarning. > > > > Wait, only Python 3.10? > > According to the policy, the

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On Sun, Nov 14, 2021 at 3:01 PM Victor Stinner wrote: > On Sun, Nov 14, 2021 at 6:34 PM Eric V. Smith wrote: > > On second thought, I guess the existing policy already does this. Maybe > > we should make it more than 2 versions for deprecations? I've written > > libraries where I support 4 or 5

[Python-Dev] Re: Proposal: Allow non-default after default arguments

On Tue, Nov 9, 2021 at 6:31 AM Steven D'Aprano wrote: > By the way, this discussion is probably better suited to the > Python-Ideas mailing list. But since we're here... > > On Tue, Nov 09, 2021 at 11:37:40AM +0100, Sebastian Rittau wrote: > > > >>To me, the "natural" solution looks like this: >

[Python-Dev] Re: Oh look, I've been subscribed to python/issues-test-2 notifications again

What notification? (I fully admit I may not have gotten one due to some team I'm in, but I have no such notification if it happened recently.) On Thu, Nov 4, 2021 at 12:16 AM Larry Hastings wrote: > > I guess this is part of the migration from bpo to GitHub issues? Maybe > the initial work

[Python-Dev] Re: PEP 663:

Rendered versions can be found at the following links: https://www.python.org/dev/peps/pep-0663/ https://python.github.io/peps/pep-0663/ On Tue, Nov 2, 2021 at 8:41 PM Ethan Furman wrote: > See the latest changes, which are mostly a (hopefully) improved abstract, > better tables, and some

[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

FYI I opened https://github.com/python/cpython/pull/29170 to loosen/correct the definition of "iterator", but I got push-back on the PR and this thread never reached a clear conclusion. As such I'll ask the SC to make a call. ___ Python-Dev mailing

[Python-Dev] Re: The Default for python -X frozen_modules.

On Mon, Sep 27, 2021 at 9:54 AM Eric Snow wrote: > We've frozen most of the stdlib modules imported during "python -c > pass" [1][2], to make startup a bit faster. Import of those modules > is controlled by "-X frozen_modules=[on|off]". Currently it defaults > to "off" but we'd like to default

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

On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev < python-dev@python.org> wrote: > On 26/09/2021 05:21, Steven D'Aprano wrote: > > [snip] > > > These are not rhetorical questions, I genuinely do not know. I *think* > > that there was an attempt to make a stable C API back in 3.2

[Python-Dev] Re: f-strings in the grammar

On Mon, Sep 20, 2021 at 8:58 AM Thomas Grainger wrote: > I don't think the python syntax should be beholden to syntax highlighting > tools, eventually some syntax feature that PEG enables will require every > parser or highlighter to switch to a similar or more powerful parse tool > But that's

[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

> >> My view of this is: >> >> A. It's not an iterator if it doesn't define `__next__`. >> >> B. It is strongly recommended that iterators also define `__iter__`. >> >> In "standards" language, I think (A) is MUST and (B) is merely OUGHT or >

[Python-Dev] Discussion about how to manage additions/removals to the stdlib

https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681 This comes from my language summit talk on the stdlib to help clarify some things about how we manage the stdlib from the perspective of additions/deletions. FYI I will be *muting this email thread

  1   2   3   4   5   6   7   8   9   10   >