Re:Python adopts a 12-month release cycle
by robomartin on Saturday November 02, 2019 @03:11AM
(#21426314)
To add to this, let's take a look at the simplest portion of the above and think about where this ultimately ends-up: As code being executed by a microprocessor; machine language.
reductor = dispatch_table.get(cls)
if reductor:
rv = reductor(x)
versus:
if reductor := dispatch_table.get(cls):
rv = reductor(x)
versus (the case of extending "="):
if reductor = dispatch_table.get(cls):
rv = reductor(x)
Now let's look at rough machine-level pseudo code.
In the first case:
- Load address of "cls" into appropriate register
- Jump to address where "dispatch_table.get()" code is located
- Upon return, the result, a memory address (pointer) is stored in a register
- Load the memory address (pointer) to where the "reductor" variable's data is located
- Store the address that came back from "dispatch_table.get()" at that location
- Compare this and jump if null
- If not null we execute the code that follows
Great. What would the pseudocode for the second case (walrus) look like:
- Load address of "cls" into appropriate register
- Jump to address where "dispatch_table.get()" code is located
- Upon return, the result, a memory address (pointer) is stored in a register
- Load the memory address (pointer) to where the "reductor" variable's data is located
- Store the address that came back from "dispatch_table.get()" at that location
- Compare this and jump if null
- If not null we execute the code that follows
Hmmm, I see a pattern here. What would it look like if we extended the functionality of "=" instead?
- Load address of "cls" into appropriate register
- Jump to address where "dispatch_table.get()" code is located
- Upon return, the result, a memory address (pointer) is stored in a register
- Load the memory address (pointer) to where the "reductor" variable's data is located
- Store the address that came back from "dispatch_table.get()" at that location
- Compare this and jump if null
- If not null we execute the code that follows
OK. Well, there's the point. If the code has to do exactly the same thing it will ultimately end-up executing exactly the same code on the processor. If it executes any more code than the old approach it will not, by definition, add any functionality, therefore, it is a waste of time. If it does exactly the same thing we should then question why it is necessary in the first place.
In the first case:
Great. What would the pseudocode for the second case (walrus) look like: Hmmm, I see a pattern here. What would it look like if we extended the functionality of "=" instead? OK. Well, there's the point. If the code has to do exactly the same thing it will ultimately end-up executing exactly the same code on the processor. If it executes any more code than the old approach it will not, by definition, add any functionality, therefore, it is a waste of time. If it does exactly the same thing we should then question why it is necessary in the first place.