New assignmens ...

Antoon Pardon antoon.pardon at vub.be
Mon Oct 25 14:33:42 EDT 2021


Op 25/10/2021 om 18:06 schreef Avi Gross via Python-list:
> Antoon,
>
> Just to be clear. I am talking about a different measure of efficiency.

No you are not.

>
> The topic here is the Python run-time parser though.

Yes and that is what I am talking about.

>  It is reading your code
> and doing whatever complex set of things it has to do to parse from a fairly
> large set of possible valid programs as well as invalid ones. I have never
> looked deeply at how it works but my guess is that somewhere in there are
> concepts like:
>
> simple_asignment_expression can look like THIS.
> complex _assignment expression can look like simple_assignment_expression OR
> THAT OR ...
>
> So to parse code you often need to look at alternate ways of connecting
> symbols and hopefully find the one and only way it has to be looked at.
> Parentheses as an example have many possible meanings and you may not know
> which meaning when you encounter it until you keep going and see where there
> may be a matching one but ignore any within a character string. I won't go
> on but the point is that the parser can jump through more hoops even in the
> most usual cases when it has to look for new cases not originally designed
> in.

IMO that extra complexity is insignificant. You really don't reduce the complexity of your
parser much if you would limit it so that indexes can only be names so that the programmer
instead of being able to write:

    var = tab[some expression]

is forced to write it as:

    index = some expression
    var = tab[index]

Because all that machinery to evaluate some expression needs to be there anyway.

In the same way we have already all the machinery present for assignments.

By putting limits on the walrus code, you are not reducing complexity, you are increasing it.
You are increasing complexity because you can't just reuse the code that handles an ordinary
assignment. You now need specific code to limit it's use.

-- 
Antoon Pardon.



More information about the Python-list mailing list