Mailman 3 March 2021 - docs

[issue42041] venv subprocess call to python resolves to wrong interpreter
by Eryk Sun 27 Mar '21

27 Mar '21

Change by Eryk Sun <eryksun(a)gmail.com>: ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42041> _______________________________________

1 0

[issue39231] Mistaken notion in tutorial
by Robert 27 Mar '21

27 Mar '21

New submission from Robert <freshbob1337(a)gmail.com>: https://docs.python.org/3/tutorial/controlflow.html 4.7.8. Function Annotations [...] "The following example has a positional argument, a keyword argument, and the return value annotated:" It is not a "positional argument" but an "optional argument". ---------- assignee: docs@python components: Documentation messages: 359443 nosy: docs@python, r0b priority: normal severity: normal status: open title: Mistaken notion in tutorial type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39231> _______________________________________

5 9

[issue43640] Add warnings to ssl.PROTOCOL_TLSv1 and ssl.PROTOCOL_TLSv1_1 docs
by Illia Volochii 27 Mar '21

27 Mar '21

New submission from Illia Volochii <illia.volochii(a)gmail.com>: TLS versions 1.0 and 1.1 have recently been deprecated. [1] ssl.PROTOCOL_SSLv2 and ssl.PROTOCOL_SSLv3 have such warnings "SSL version 2 is insecure. Its use is highly discouraged." [2] We have to add such warnings to ssl.PROTOCOL_TLSv1 and ssl.PROTOCOL_TLSv1_1 too. [1] https://datatracker.ietf.org/doc/rfc8996/ [2] https://docs.python.org/3.10/library/ssl.html#ssl.PROTOCOL_SSLv2 ---------- assignee: docs@python components: Documentation messages: 389606 nosy: docs@python, illia-v priority: normal severity: normal status: open title: Add warnings to ssl.PROTOCOL_TLSv1 and ssl.PROTOCOL_TLSv1_1 docs type: enhancement versions: Python 3.10 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43640> _______________________________________

1 1

[issue43605] Eval/exec and comprehension scopes unclear in documentation
by Cong Ma 27 Mar '21

27 Mar '21

Change by Cong Ma <m.cong(a)protonmail.ch>: ---------- keywords: +patch pull_requests: +23787 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25039 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43605> _______________________________________

1 0

[issue39616] SSLContext.check_hostname description is inaccurate wrt match_hostname
by Ville Skyttä 27 Mar '21

27 Mar '21

New submission from Ville Skyttä <ville.skytta(a)iki.fi>: Doc says "Whether to match the peer cert’s hostname with match_hostname() in SSLSocket.do_handshake()." but match_hostname() is no longer used to do that in the first place, OpenSSL is used for that. check_hostname affects the OpenSSL usage, too. ---------- assignee: docs@python components: Documentation messages: 361892 nosy: docs@python, scop priority: normal severity: normal status: open title: SSLContext.check_hostname description is inaccurate wrt match_hostname type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39616> _______________________________________

3 7

[issue43605] Eval/exec and comprehension scopes unclear in documentation
by Cong Ma 27 Mar '21

27 Mar '21

Cong Ma <m.cong(a)protonmail.ch> added the comment: Some more context: Issue 37646. The demo in that one was "eval inside list-comprehension-scope", while this one is the other way around. Perhaps another example may better illustrate the interplay between eval and the execution environment: ``` def f(): x = 1 def g(): return eval("x") return g enc = f() enc() ``` We get ``NameError: name 'x' is not defined``. The reason is that, during compilation the compiler doesn't and cannot care about what the string "x" means as an argument to eval(). To the compiler it's just a string constant passed to a function, and it's not much different from ``` return print("x") ``` The compiler decides that the enclosed function g() has no locals in its block. And since there's no global with the name ``x`` either, when the dynamic expression is evaluated in eval() in that environment, the name doesn't resolve, because "eval() doesn't have access to the enclosing scope". But the following is different: ``` def f(): x = 1 def g(): x # <----- return eval("x") return g enc = f() enc() # return value: 1 ``` The marked line introduces name ``x`` as a local by virtue of merely having it in an expression-statement. Inside the function block of g(), we can imagine that the name resolution "goes up one level" into the enclosing block of f() where it is bound to the int object. When eval() is called there, the name does resolve. I'm trying to think up a mental model but I'm afraid I can't find a simple one, except "once compiled, it's compiled, and eval() must learn to work with the already-compiled code". A much more in-depth description of name binding and execution in CPython is given here: https://tenthousandmeters.com/blog/python-behind-the-scenes-5-how-variables… especially in the section "``LOAD_DEREF`` and ``STORE_DEREF``". ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43605> _______________________________________

1 0

[issue43605] Eval/exec and comprehension scopes unclear in documentation
by Cong Ma 27 Mar '21

27 Mar '21

Cong Ma <m.cong(a)protonmail.ch> added the comment: > sum(get(i) for i in range(len(l))) This expression inside the body of ``func()`` references the name "get" and "l" (ell), both are local to the scope introduced by ``func()``. More specifically, these two names are referenced in the unnamed inner scope introduced by the generator-expression ``(get(i) for i in range(len(l)))``. It's as if you've passed into that inner scope the locals already introduced in func() by argument passing, e.g. ``` def func(...): get = ... ell = ... def genexpr(a, b): return <expression using a and b> sum(genexpr(get, ell)) ``` > eval("get(0) + get(1) + get(2) + get(3)") The expression in the string doesn't introduce its own scope. The name "get" is resolved because without additional arguments, eval() gets the locals from the calling scope's locals, which is where the name "get" came. > eval("sum(get(i) for i in range(len(l)))", locals()) This tells eval() to use the calling scope's locals (the value returned by the call ``locals()``) as the globals for the evaluation of the expression in the string. When eval() executes the compiled code, it's as if that piece of code lives in an environment where names like "gets" and "l" (ell) are top-level. Therefore these names are resolved. > eval("sum(get(i) for i in range(len(l)))") Without explicitly telling eval() which globals/locals namespaces to use, eval() uses the current calling scope's. This is as if it were called like eval("sum(get(i) for i in range(len(l)))", globals(), locals()) A problem arises. The generator expression in the string introduces an anonymous inner scope (let's call that scope "the box"). Inside the box, the name "i" is a local, there's no problem. But for the name "get", it's not local to the box, and it's not a global. Unlike other kinds of enclosed scope (for example, one introduced by an inner ``def`` block), "the box" has no way to look up names in enclosing scopes. This is the limitation referred to by the Language Reference's section on dynamic execution. These are my attempts to explain why something works while others don't, based on my own understanding. I hope this helps somewhat, and if I made a mistake anywhere please correct them. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43605> _______________________________________

1 0

[issue43605] Eval/exec and comprehension scopes unclear in documentation
by Bruno Loff 27 Mar '21

27 Mar '21

Bruno Loff <bruno.loff(a)gmail.com> added the comment: Hmm yes, some more words in the documentation might help. Does anyone understand why it happens, though? Specifically, note that sum(get(i) for i in range(len(l))) or eval("get(0) + get(1) + get(2) + get(3)") or eval("sum(get(i) for i in range(len(l)))", locals()) work just fine, but eval("sum(get(i) for i in range(len(l)))") fails, which is really confusing. I have no mental model of what is happening that allows for the first thing to work, but disallows for the second thing. I understand it has something to do with the creation of a new subscope when the comprehension is run, but other than that, I don't really understand. Also, ideally, the last thing should work, too. I am teaching programming to college students and I could not explain to them why the first three worked but the last one failed. There was simply nothing I could say that would give them a good mental model for the execution. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43605> _______________________________________

1 0

[issue43605] Eval/exec and comprehension scopes unclear in documentation
by Cong Ma 27 Mar '21

27 Mar '21

Cong Ma <m.cong(a)protonmail.ch> added the comment: I'm preparing an update to the documentation of eval/exec. There are several issues, but chiefly I'll link to the appropriate sections in the Language Reference, and clean up some other inaccuracies. When it's ready I'll submit a PR for core devs to review. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43605> _______________________________________

1 0

[issue43605] Eval/exec and comprehension scopes unclear in documentation
by Cong Ma 27 Mar '21

27 Mar '21

Cong Ma <m.cong(a)protonmail.ch> added the comment: > I think it is *very* reasonable to expect that calling eval() on a string should have the exact same effect as if the code that is inside the eval had been written as part of the source code. I don't think Python's execution model is defined this way. The documentation on execution model says: > The eval() and exec() functions do not have access to the full environment for resolving names. Names may be resolved in the local and global namespaces of the caller. Free variables are not resolved in the nearest enclosing namespace, but in the global namespace. > footnote: This limitation occurs because the code that is executed by these operations is not available at the time the module is compiled. https://docs.python.org/3/reference/executionmodel.html#interaction-with-dy… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43605> _______________________________________

1 0