[Python-ideas] Jump to function as an an alternative to call function

[Kirill Balunov]

пн, 20 авг. 2018 г. в 17:23, Steven D'Aprano <steve at pearwood.info>:

> On Sun, Aug 19, 2018 at 06:18:56PM +0300, Kirill Balunov wrote:
> [...]
> [Kirill]
> > Let me disagree with you. While CPython is only one of the
> implementations
> > of the Python language, it is the most common one and defacto is
> considered
> > as a standard.
>
> Not in this case. If CPython intended this to be the language behaviour,
> it should specify that limitation instead of merely giving a doc warning
> that changes "may not" affect the local variables.
>
> In fact, the warning in the docs is too strong. Modifying locals()
> inside a class or module scope is allowed, and works fine. It is only
> functions which is problematic.
>
>
I think I was pretty clear, that I only spoke about `locals` behavior
inside functions and all its derivatives. At least I tried :) Talking about
class and module, as for me, modifying `locals()`
inside a class or module scope is allowed but is far from the right way to
do.

The phrase `may not affect` is the worst phrase for deterministic system.
Your program may work or may not work correctly depending on the underlying
Python implementation, but you would not know about this because there will
be no error and no warning. Good luck fixing such bugs.


>
> > Therefore, all the others, to be compliant, try to replicate
> > all subtleties and features of the basic implementation - CPython.
>
> Implementations are expected to obey the documented behaviour (unless
> given special dispensation to break the rules, which I think has
> happened once or twice with MicroPython). For behaviour which isn't
> dpcumented, it is true that implementations *often* try to copy CPython,
> but that's not mandatory and there are exceptions.
>
>
I think you are talking about recent discussion of MicroPython's `dict`
implementation (that the order is not guaranteed?) It is a necessary trade
off for them given their niche (if I understand correctly the explanation
given by Paul Sokolovsky).


> [...]
>
> Users of CPython frequently rely on CPython implementation details. Why
> do you think Jython and IronPython users will be different?
>
>
Hmm, what do you mean? It seems to me that everything happens the other way
round. For example, recent attempts of numpy to make numpy more PyPy
friendly. In fact, I do not know anyone who specifically rely on CPython
implementation details in their production code.

with kind regards,
-gdg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180821/2ff35044/attachment.html>