[Python-Dev] Comments on PEP 558 (Defined semantics for locals() )

2020-01-22 Thread Mark Shannon

Hi,

First of all I want to say that I'm very much in favour of the general 
idea behind PEP 558. Defined semantics is always better than undefined 
semantics :)


However, I think there are a few changes needed:

1. Don't add anything to the C API, please.
   Frame attributes can be accessed via `PyObject_GetAttr[String]`.

2. Don't make the behaviour dependent on whether "tracing" is turned on. 
   Doing so forces debuggers to use sys.settrace which is horribly 
slow. It also makes the implementation more complex, and has no benefit 
AFAICT.


3. Don't store write-through proxies in the frame, but make proxies 
retain a reference to the frame. This would reduce the size and 
complexity of code for handling frames. Clean up of the frame would 
occur naturally via reference count when all proxies have been reclaimed.




The proposed implementation is hard to reason about and I am not 
confident that it will not introduce some new subtle bugs to replace the 
ones it seeks to remove.
Any implementation that has functions with "Borrow" and "BreakCycles" in 
their names makes me nervous.



A simpler conceptual model, which I believe could be made reliable, 
would be:


No change for non-function frames (as PEP 558 currently proposes).

Each access to `frame.f_locals` (for function frames) should return a 
new proxy object.


This proxy object would have dict-like, write-through semantics for 
variables in the frame. For keys that do not match variable names, an 
exception would be raised. This means that all proxies for a single 
frame will have value equivalence; object equivalence is not needed.
I.e. for a frame `f`, `f.f_locals == f.f_locals` would be True, even 
though `f.f_locals is f.f_locals` would be False.


Cheers,
Mark.
___
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/TSHCB4ZHC4XUVGJ3MX4D7HCHMTB6WROD/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Documenting Python's float.__str__()

2020-01-22 Thread Vedran Čačić
> ints print the same in just about every single programming language that
uses base ten Arabic-Hindu digits 0...9. It's kind of a universal.

Not actually true: C64's Basic V2 printed positive numbers with space in
front.
-- 
Vedran Čačić
___
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/ALURGURCJTE5VPYXUTTXDWYHFB22BQBT/
Code of Conduct: http://python.org/psf/codeofconduct/