Hello, On Thu, 14 Jan 2021 23:00:06 +1300 Greg Ewing <greg.ew...@canterbury.ac.nz> wrote:
> On 14/01/21 3:32 pm, Terry Reedy wrote: > > I say 'yes', because the purpose of logging is to document what > > happens, and if nothing happens, there is nothing to document. > > Wrapping a .__bool__ in a logging decorator might be part of > > testing it. > > Or it might be something else. > > It would be fine to *define* __bool__ as something the compiler > is allowed to optimise away. Yes, and the talk was exactly about how to *proceed* with (re)defining __bool__ (and other dunders, then other runtime inefficiencies) as something the compiler is allowed to optimise away. To retrace the outline: 1. Current semantics doesn't say that __bool__ can be optimized away, and it stays that way. (Compare that to the parallel discussion of PEP649 - it tries to change existing semantics by disallowing variable annotations inside the "if" statement, and that's raised as a concern). 2. Instead, a new semantic mode is introduced, which needs to be explicitly enabled. 3. Now the problem comes up about compatibility of the existing source code with the new mode. 4. It's resolved by requiring __bool__ and other dunders to be annotated "pure" (tentative code-name). The code which doesn't have all __bool__, etc. methods annotated as such cannot be run in the new semantic mode (and benefit from any optimizations it may offer), and has to continue be run in the old mode. (And note that annotated code still can run in the old mode either.) 5. Now, stamping annotations is nice, but the code should correspond to them, so there should be ability to "typecheck" such annotated code (more like "behavior-check", though effects tracking is also part of the type theory). It can be handled in the same way as typechecking existing type annotations happen - by external tools. > But that's a different thing from > "purity" (which is hard to pin down in an imperative language). At the beginning of this sub-thread, example of Haskell was given. It went the different way - of banning any mutability and side-effects at all, then making heroic efforts of introducing concepts which would make writing programs under such model still surmountable, like monads, etc. That was hard. It didn't stop them. We here talk about evolutionary, and clearly delinated adjustments to Python semantics, based on the experience with efficiently executing Python code. Certainly, much less hard than what Haskell did. > -- > Greg [] -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2AI7DRSQ6AJUNQSVXU672DQ3OOWVQNV7/ Code of Conduct: http://python.org/psf/codeofconduct/
