[Chris Angelico] > That right there is unacceptable. You should not have to know the > destination to understand what something fundamentally is.
You don't *have* to know what the parameter "key" is to know that (value[card.suit] ... with card) is a function. You can identify that it's a function just by reading the full expression. However, if you don't know what "key" is, then it'll cause far more confusion than the late declaration of the function's parameters. [Chris Angelico] > You can't redefine language syntax based on the function being called. That's not at all what I suggested. You were walking through my example from the reader's perspective. I was explaining how the reader will often have plenty of context about what they're reading before they get to the signature declaration. Whether it be because they know what the "key" parameter means or because they know "card" is undeclared or both. I never claimed the language syntax should be based on the function being called. func = value[card.suit] if card not in wilds else wild_value with card Works independent of the function being called. It's just not a common use case because it obviates the expressiveness of anonymous functions. You might as well use a "def" statement. The thing that makes callbacks difficult is not knowing how they're called. I tried to throw a little JavaScript into my curriculum once thinking "how bad can it be?" and suggested my students work on a project using the Force Directed Graph from D3.js <https://bl.ocks.org/mbostock/1062288>. That was a HUGE mistake not because anonymous functions are confusing but because the example (at the time) had no documentation at all (like this one <https://bl.ocks.org/mbostock/4062045>) and used mysterious callbacks everywhere. The main documentation for D3.js is super difficult to navigate, when all you want to do is slightly modify one of the examples (use svg images for the nodes and have stats display "on mouse over"). If you don't know what "".join() does, then you're going to have trouble making sense of: def initials(person): return "".join(name[0] + "." for name in person.names if name) The late assignment of the name variable will NOT be your main source of confusion. If you do know what "".join() does, then it should take you much less context to realize you're reading a generator expression. By the time you read the yet-to-be-assigned "name" variable you should be tipped off. On Tue, Aug 21, 2018 at 1:58 PM, Chris Angelico <ros...@gmail.com> wrote: > On Wed, Aug 22, 2018 at 4:56 AM, Abe Dillon <abedil...@gmail.com> wrote: > > [Chris Angelico] > >> > >> Okay, let's read that. > >> hand = # we're assigning this to the name 'hand' > >> sorted( # calling the function named 'sorted' > >> cards, # positional argument, whatever's in the 'cards' variable > >> by= # keyword argument, what comes next is the 'by' argument > >> value[card.suit] # subscript 'value' with 'card.suit' > >> if card is not wild # yep > >> else max_value # so we have an alternative > >> with card # WAIT WAIT WAIT > >> Once you get to 'with card', you have to go back and completely > >> reinterpret everything prior to that as a function. > > > > > > The revelation that it's a function should come when you read the "by" or > > "key". If you don't know what that parameter is, then that's where the > "wait > > wait wiat!" should happen. > > That right there is unacceptable. You should not have to know the > destination to understand what something fundamentally is. You can't > redefine language syntax based on the function being called. > > ChrisA > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
