[Python-Dev] Stable ABI – PEP 667: Consistent views of namespaces

2021-08-24 Thread Petr Viktorin 

On 23. 08. 21 5:07, Guido van Rossum wrote:
On Sat, Aug 21, 2021 at 8:52 PM Nick Coghlan > wrote:

[...]

Code that uses PyEval_GetLocals() will NOT continue to operate
safely under PEP 667: all such code will raise an exception at
runtime, and need to be rewritten to use a new API with different
refcounting semantics.


Yeah, I did a double take too when I read what Mark wrote. He uses 
"safe" in a very technical sense, meaning that you get a Python 
exception but not a crash, and no leak or writing freed memory. And it's 
true, any caller to PyEval_GetLocals() should check for errors, and 
there are several error conditions that may occur. (The docs are 
incomplete, they say "returns NULL if no frame is executing" but they 
fail to mention that it sets an exception in that case and in other cases.)


But PyEval_Locals() is in the Stable ABI (though I have no idea why),


This was a case of "now is better than never" – a line had to be drawn 
somewhere, and having a clear line is better than spending years to get 
the ideal line.



For these PEPs, I think the discussion should stick to the desired 
semantics first; backwards compatibility for the Stable ABI can be 
bolted on to whatever solution comes up.
"Regular" backwards compatibility is another matter – IMO it's important 
to keep things like debuggers working as much as possible.



we have essentially two options: keep it working, or make it return an 
error. We can't delete it. And it returns a borrowed reference, which 
makes it problematic to let it return a "f_locals proxy object" since 
those proxies are not cached on the frame.


From PEP 652 "Maintaining the Stable ABI":


Future Python versions may deprecate some members of the Stable ABI. Deprecated 
members will still work, but may suffer from issues like reduced performance 
or, in the most extreme cases, memory/resource leaks.


There are many things that can be done:

- I believe we can add an extra pointer on frame objects, lazily 
populated, just for backward compatibility.

- The bad old API can introduce a reference cycle.
- We can incref the "borrowed" reference and introduce a leak.
- The bad old API can start always raising an exception. (Last on the 
list, since if you can't fix the source and recompile an extension, 
there's no workaround.)



In all cases, extension authors can fix things by moving to the new API.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/LQARGPG4ROL6MJOQ4Y7CNT57TT7ON22S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 667: Consistent views of namespaces

2021-08-24 Thread Patrick Reader 
On 24/08/2021 06:27, Steven D'Aprano wrote:
> Wouldn't that attempt to resolve global y, rather than local y? Unless
> there is a change to the current behaviour of the compiler, I think you 
> need to fool the compiler:
>
>if False: y = 0  # anywhere inside the function is okay
Time to add a `nonnonlocal` statement ;)
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/WMUK3XLP4GOR25ELCF3LUTAWT6YIPDSI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 667: Consistent views of namespaces

2021-08-24 Thread MRAB 

On 2021-08-24 17:55, Patrick Reader wrote:

On 24/08/2021 06:27, Steven D'Aprano wrote:

Wouldn't that attempt to resolve global y, rather than local y? Unless
there is a change to the current behaviour of the compiler, I think you 
need to fool the compiler:


   if False: y = 0  # anywhere inside the function is okay

Time to add a `nonnonlocal` statement ;)


Or perhaps use "not nonlocal"? :-)
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/USZ5FOQ6WF365VC7C4ZH4K4TR5AW2X2Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] A ban from Core Developer spaces.

2021-08-24 Thread Thomas Wouters 
All,

After some consideration at our weekly meeting (this monday), and a
recommendation from the Conduct WG (last friday), the Steering Council has
decided to ban Marco Sulla from all Core Developer spaces for at least a
year. (For the record, Brett abstained from voting on this issue.) We also
agreed to add Ethan to the python-dev moderators, who's already taken the
more specific action of banning Marco from python-dev for 3 months. If
anyone else is interested in assisting with moderation on python-dev,
please let us know.

Marco wasn't solely responsible for how bad some of the discussion went,
but his messages were the ones that clearly crossed the line, both in tone
and in language, and it isn't the first time; as he's already pointed out,
he was previously banned from discuss.python.org for the same kind of
behaviour. We do want to admonish and encourage everyone who participated
in the discussions to reconsider their posts. We've heard from quite a lot
of people how badly the whole conversation was viewed, and how much it
alienated people -- both potential new contributors and old hands on
python-dev.

We've said before that this behaviour has to stop, and we do mean it. At
this point we need to have a larger discussion about the future of
python-dev, but we want to handle that separately from this particular
incident. We’ll think a bit more about what the options are, and start a
separate discussion about it later this week.

For the whole SC,
Thomas.
-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/5QHGDMU4CJ6KGS5G4CHSXTZF5AZDIVLB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Should PEP 8 be updated for Python 3 only?

2021-08-24 Thread Christopher Barker 
I just noticed that PEP 8 has quite a few references to Python 2. Perhaps
it's time to remove those.

There are more and more folks that have never learned or used Python 2 --
having those notes in PEP 8 is just confusing.

And for folks that are still maintaining Py 2 code --  it's probably too
late for PEP 8 for those code bases anyway.

If I make a PR, will it be considered?

-CHB


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/MK7N36L3XCXVY5R4DIIYIDU2W7EGJKZ3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

2021-08-24 Thread Guido van Rossum 
Since PEP 8 is a "living document" that is occasionally updated, I think
that's reasonable. Don't go overboard. I found 10 occurrences of the string
"python 2" in the text. You might also want to strike the paragraph that
links to reference [6].

On Tue, Aug 24, 2021 at 9:42 PM Christopher Barker 
wrote:

> I just noticed that PEP 8 has quite a few references to Python 2. Perhaps
> it's time to remove those.
>
> There are more and more folks that have never learned or used Python 2 --
> having those notes in PEP 8 is just confusing.
>
> And for folks that are still maintaining Py 2 code --  it's probably too
> late for PEP 8 for those code bases anyway.
>
> If I make a PR, will it be considered?
>
> -CHB
>
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/MK7N36L3XCXVY5R4DIIYIDU2W7EGJKZ3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

2021-08-24 Thread Christopher Barker 
On Tue, Aug 24, 2021 at 9:53 PM Guido van Rossum  wrote:

> Since PEP 8 is a "living document" that is occasionally updated, I think
> that's reasonable. Don't go overboard. I found 10 occurrences of the string
> "python 2" in the text. You might also want to strike the paragraph that
> links to reference [6].
>

will do -- hopefully I'll find some time for this tomorrow.

-CHB




> On Tue, Aug 24, 2021 at 9:42 PM Christopher Barker 
> wrote:
>
>> I just noticed that PEP 8 has quite a few references to Python 2. Perhaps
>> it's time to remove those.
>>
>> There are more and more folks that have never learned or used Python 2 --
>> having those notes in PEP 8 is just confusing.
>>
>> And for folks that are still maintaining Py 2 code --  it's probably too
>> late for PEP 8 for those code bases anyway.
>>
>> If I make a PR, will it be considered?
>>
>> -CHB
>>
>>
>> --
>> Christopher Barker, PhD (Chris)
>>
>> Python Language Consulting
>>   - Teaching
>>   - Scientific Software Development
>>   - Desktop GUI and Web Development
>>   - wxPython, numpy, scipy, Cython
>> ___
>> Python-Dev mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/[email protected]/message/MK7N36L3XCXVY5R4DIIYIDU2W7EGJKZ3/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
>


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/DRYMTFYBEUYF2KFNHXYUINYSTS5AZ7YM/
Code of Conduct: http://python.org/psf/codeofconduct/