On Thu, Jul 29, 2021 at 4:52 PM Nick Coghlan wrote:
>
> On Fri, 30 Jul 2021, 6:05 am Mark Shannon, wrote:
>>
>> Hi Nick,
>>
>> Our discussion on PEP 558 got me thinking
>> "What is the simplest thing that would work?".
>>
>> This is what I came up (in the form of a draft PEP):
>>
On Fri, 30 Jul 2021, 6:05 am Mark Shannon, wrote:
> Hi Nick,
>
> Our discussion on PEP 558 got me thinking
> "What is the simplest thing that would work?".
>
> This is what I came up (in the form of a draft PEP):
> https://github.com/markshannon/peps/blob/pep-locals/pep-06xx.rst
>
> It doesn't
On Fri, 30 Jul 2021, 8:47 am Barry Warsaw, wrote:
>
> Hello Nick, Ethan,
>
> The Python Steering Council reviewed PEP 467 -- Minor API improvements for
> binary sequences at our 2021-07-26 meeting.
>
> Thank you for work on this PEP. We’re generally very favorable for adding
> to Python 3.11
Hello Nick, Ethan,
The Python Steering Council reviewed PEP 467 -- Minor API improvements for
binary sequences at our 2021-07-26 meeting.
Thank you for work on this PEP. We’re generally very favorable for adding to
Python 3.11 the features and APIs described in the PEP. We have some
Hi Nick,
Our discussion on PEP 558 got me thinking
"What is the simplest thing that would work?".
This is what I came up (in the form of a draft PEP):
https://github.com/markshannon/peps/blob/pep-locals/pep-06xx.rst
It doesn't have O(1) len(f_locals), and it does break
`PyEval_GetLocals()`
On Thu, Jul 29, 2021 at 3:47 AM Mark Shannon wrote:
> Hi everyone,
>
> I would like to repeal PEP 509. We don't really have a process for
> repealing a PEP. Presumably I would just write another PEP.
>
Yeah, it's probably a new PEP explaining why the first PEP turned out to
not work out since
On 7/29/2021 6:17 PM, Barry Warsaw wrote:
On Jul 29, 2021, at 05:55, Steve Dower wrote:
Maybe we should have a "Type" other than Standards Track for PEPs that are
documenting implementation designs, rather than requirements for standardisation?
Wouldn’t Informational fill that need?
The documentation for PyTypeObject.tp_base
(https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_base) says the
following:
> Note: Slot initialization is subject to the rules of initializing
> globals. C99 requires the initializers to be “address constants”.
> Function designators
On Jul 29, 2021, at 05:55, Steve Dower wrote:
>
> Maybe we should have a "Type" other than Standards Track for PEPs that are
> documenting implementation designs, rather than requirements for
> standardisation?
Wouldn’t Informational fill that need?
-Barry
signature.asc
Description:
Hi Steve,
On 29/07/2021 1:55 pm, Steve Dower wrote:
On 7/29/2021 11:41 AM, Mark Shannon wrote:
The dictionary version number is currently unused in CPython and just
wastes memory. I am not claiming that we will never need it, just that
we shouldn't be required to have it. It should be an
On 7/29/2021 11:41 AM, Mark Shannon wrote:
The dictionary version number is currently unused in CPython and just
wastes memory. I am not claiming that we will never need it, just that
we shouldn't be required to have it. It should be an internal
implementation detail that we can add or remove
+1
2021年7月29日(木) 19:46 Mark Shannon :
> Hi everyone,
>
> I would like to repeal PEP 509. We don't really have a process for
> repealing a PEP. Presumably I would just write another PEP.
>
> Before I do so, I would like to know if anyone thinks we should keep
> PEP 509.
>
> The dictionary version
Maybe you should also mention that in 3.11 we’re introducing a new concept,
dict *keys* version, which is more useful (for the specializing interpreter
anyway).
On Thu, Jul 29, 2021 at 12:47 Mark Shannon wrote:
> Hi everyone,
>
> I would like to repeal PEP 509. We don't really have a process
Hi everyone,
I would like to repeal PEP 509. We don't really have a process for
repealing a PEP. Presumably I would just write another PEP.
Before I do so, I would like to know if anyone thinks we should keep
PEP 509.
The dictionary version number is currently unused in CPython and just
14 matches
Mail list logo
