On Thu, Dec 2, 2021 at 2:47 AM David Lukeš <dafydd.lu...@gmail.com> wrote:
>
> This was probably mentioned at some point (apologies, can't afford to
> read the entire thread), but since the issue of left-to-right vs.
> early-first-then-late binding was hotly debated, I just want to point out
> that left-to-right better preserves scoping intuitions:
>
> foo = 42
> def bar(@baz=foo, foo=1):
> return baz, foo
>
> With left-to-right, bar() returns (42, 1) (or whatever other value the
> foo global currently has). With early-first-then-late, it returns (1,
> 1). And according to the current version of the PEP, it's essentially
> undefined behavior, though AFAICS, the possibility that baz would take
> its value from global foo isn't even considered.
There are only two possible interpretations: either it uses the
provided foo (or early-bound default), or it fails with
UnboundLocalError. Under no circumstances would it be able to see a
global. This isn't a class namespace, so the name 'foo' is always
local.
> As a teacher, I'd much rather teach/explain the first option, because
> in most of Python, you can figure out what value a name refers to by
> looking to the left and above of where it's used, and if you can't find
> it in the local scope, check globals.
>
> (One prominent place where this doesn't hold is comprehensions/genexprs,
> which in practice tend to be a learning bump for beginners.)
That's an oversimplification:
foo = 42
def bar():
print(foo)
foo = 1
This won't print 42. But with that understanding ("locals are locals
no matter where you use them"), late-bound defaults are the same as
any other locals.
> The PEP doesn't have any examples of what the syntax for *assigning*
> late bound arguments is, so I'm assuming there's no special syntax? As
> in, bar can be called e.g. as bar(1, 2), bar(baz=1, foo=2) or bar(foo=1,
> baz=2)? That makes sense, but I think it's a small argument in favor of
> a prefix notation, so that = is kept the same across definitions and
> calls. Somehow, I would expect my students to be more likely to
> erroneously think they need to replicate => and call bar as bar(baz=>1),
> and less likely to write bar(@baz=1), especially with that barrier
> mnemonic. Just a hunch though.
Definitely no special syntax. This makes no changes to the way
functions are called, only what happens with omitted args.
ChrisA
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/CLODWGM3IRSCXDH2EUAD57BJ7OLUR4O2/
Code of Conduct: http://python.org/psf/codeofconduct/
