Why is setTimeout(fn, 0) sometimes useful?

Questions : Why is setTimeout(fn, 0) sometimes useful?

I’ve recently run into a rather nasty bug, wherein the code was loading a <select> dynamically via JavaScript. This dynamically loaded <select> had a pre-selected value. In IE6, we already had code to fix the selected <option>, because sometimes the <select>‘s selectedIndex value would be out of sync with the selected <option>‘s index attribute, as below:

field.selectedIndex = element.index; 

However, this code wasn’t working. Even though the field’s selectedIndex was being set correctly, the wrong index would end up being selected. However, if I stuck an alert() statement in at the right time, the correct option would be selected. Thinking this might be some sort of timing issue, I tried something random that I’d seen in code before:

var wrapFn = (function() { var myField = field; var myElement = element; return function() { myField.selectedIndex = myElement.index; } })(); setTimeout(wrapFn, 0); 

And this worked!

I’ve got a solution for my problem, but I’m uneasy that I don’t know exactly why this fixes my problem. Does anyone have an official explanation? What browser issue am I avoiding by calling my function “later” using setTimeout()?

Total Answers: 19 Answers 19

Popular Answers:

  1. In the question, there existed a race condition between:

    1. The browser’s attempt to initialize the drop-down list, ready to have its selected index updated, and
    2. Your code to set the selected index

    Your code was consistently winning this race and attempting to set drop-down selection before the browser was ready, meaning that the bug would appear.

    This race existed because JavaScript has a single thread of execution that is shared with page rendering. In effect, running JavaScript blocks the updating of the DOM.

    Your workaround was:

    setTimeout(callback, 0) 

    Invoking setTimeout with a callback, and zero as the second argument will schedule the callback to be run asynchronously, after the shortest possible delay – which will be around 10ms when the tab has focus and the JavaScript thread of execution is not busy.

    The OP’s solution, therefore was to delay by about 10ms, the setting of the selected index. This gave the browser an opportunity to initialize the DOM, fixing the bug.

    Every version of Internet Explorer exhibited quirky behaviors and this kind of workaround was necessary at times. Alternatively it might have been a genuine bug in the OP’s codebase.

    See Philip Roberts talk “What the heck is the event loop?” for more thorough explanation.

  2. Take a look at John Resig’s article about How JavaScript Timers Work. When you set a timeout, it actually queues the asynchronous code until the engine executes the current call stack.

  3. Browsers have a process called “main thread”, that is responsible for executing some JavaScript tasks, UI updates e.g.: painting, redraw, reflow, etc. JavaScript tasks are queued to a message queue and then are dispatched to the browser’s main thread to be executed. When UI updates are generated while the main thread is busy, tasks are added into the message queue.

  4. There are conflicting upvoted answers here, and without proof there is no way to know whom to believe. Here is proof that @DVK is right and @SalvadorDali is incorrect. The latter claims:

    “And here is why: it is not possible to have setTimeout with a time delay of 0 milliseconds. The Minimum value is determined by the browser and it is not 0 milliseconds. Historically browsers sets this minimum to 10 milliseconds, but the HTML5 specs and modern browsers have it set at 4 milliseconds.”

    The 4ms minimum timeout is irrelevant to what is happening. What really happens is that setTimeout pushes the callback function to the end of the execution queue. If after setTimeout(callback, 0) you have blocking code which takes several seconds to run, the callback will not be executed for several seconds, until the blocking code has finished. Try this code:

    function testSettimeout0 () { var startTime = new Date().getTime() console.log('setting timeout 0 callback at ' +sinceStart()) setTimeout(function(){ console.log('in timeout callback at ' +sinceStart()) }, 0) console.log('starting blocking loop at ' +sinceStart()) while (sinceStart() < 3000) { continue } console.log('blocking loop ended at ' +sinceStart()) return // functions below function sinceStart () { return new Date().getTime() - startTime } // sinceStart } // testSettimeout0 

    Output is:

    setting timeout 0 callback at 0 starting blocking loop at 5 blocking loop ended at 3000 in timeout callback at 3033 
  5. One reason to do that is to defer the execution of code to a separate, subsequent event loop. When responding to a browser event of some kind (mouse click, for example), sometimes it’s necessary to perform operations only after the current event is processed. The setTimeout() facility is the simplest way to do it.

    edit now that it’s 2015 I should note that there’s also requestAnimationFrame(), which isn’t exactly the same but it’s sufficiently close to setTimeout(fn, 0) that it’s worth mentioning.

  6. Both of these two top-rated answers are wrong. Check out the MDN description on the concurrency model and the event loop, and it should become clear what’s going on (that MDN resource is a real gem). And simply using setTimeout can be adding unexpected problems in your code in addition to “solving” this little problem.

    What’s actually going on here is not that “the browser might not be quite ready yet because concurrency,” or something based on “each line is an event that gets added to the back of the queue”.

    The jsfiddle provided by DVK indeed illustrates a problem, but his explanation for it isn’t correct.

    What’s happening in his code is that he’s first attaching an event handler to the click event on the #do button.

    Then, when you actually click the button, a message is created referencing the event handler function, which gets added to the message queue. When the event loop reaches this message, it creates a frame on the stack, with the function call to the click event handler in the jsfiddle.

    And this is where it gets interesting. We’re so used to thinking of Javascript as being asynchronous that we’re prone to overlook this tiny fact: Any frame has to be executed, in full, before the next frame can be executed. No concurrency, people.

    What does this mean? It means that whenever a function is invoked from the message queue, it blocks the queue until the stack it generates has been emptied. Or, in more general terms, it blocks until the function has returned. And it blocks everything, including DOM rendering operations, scrolling, and whatnot. If you want confirmation, just try to increase the duration of the long running operation in the fiddle (e.g. run the outer loop 10 more times), and you’ll notice that while it runs, you cannot scroll the page. If it runs long enough, your browser will ask you if you want to kill the process, because it’s making the page unresponsive. The frame is being executed, and the event loop and message queue are stuck until it finishes.

    So why this side-effect of the text not updating? Because while you have changed the value of the element in the DOM — you can console.log() its value immediately after changing it and see that it has been changed (which shows why DVK’s explanation isn’t correct) — the browser is waiting for the stack to deplete (the on handler function to return) and thus the message to finish, so that it can eventually get around to executing the message that has been added by the runtime as a reaction to our mutation operation, and in order to reflect that mutation in the UI.

    This is because we are actually waiting for code to finish running. We haven’t said “someone fetch this and then call this function with the results, thanks, and now I’m done so imma return, do whatever now,” like we usually do with our event-based asynchronous Javascript. We enter a click event handler function, we update a DOM element, we call another function, the other function works for a long time and then returns, we then update the same DOM element, and then we return from the initial function, effectively emptying the stack. And then the browser can get to the next message in the queue, which might very well be a message generated by us by triggering some internal “on-DOM-mutation” type event.

    The browser UI cannot (or chooses not to) update the UI until the currently executing frame has completed (the function has returned). Personally, I think this is rather by design than restriction.

    Why does the setTimeout thing work then? It does so, because it effectively removes the call to the long-running function from its own frame, scheduling it to be executed later in the window context, so that it itself can return immediately and allow the message queue to process other messages. And the idea is that the UI “on update” message that has been triggered by us in Javascript when changing the text in the DOM is now ahead of the message queued for the long-running function, so that the UI update happens before we block for a long time.

    Note that a) The long-running function still blocks everything when it runs, and b) you’re not guaranteed that the UI update is actually ahead of it in the message queue. On my June 2018 Chrome browser, a value of 0 does not “fix” the problem the fiddle demonstrates — 10 does. I’m actually a bit stifled by this, because it seems logical to me that the UI update message should be queued up before it, since its trigger is executed before scheduling the long-running function to be run “later”. But perhaps there’re some optimisations in the V8 engine that may interfere, or maybe my understanding is just lacking.

    Okay, so what’s the problem with using setTimeout, and what’s a better solution for this particular case?

    First off, the problem with using setTimeout on any event handler like this, to try to alleviate another problem, is prone to mess with other code. Here’s a real-life example from my work:

    A colleague, in a mis-informed understanding on the event loop, tried to “thread” Javascript by having some template rendering code use setTimeout 0 for its rendering. He’s no longer here to ask, but I can presume that perhaps he inserted timers to gauge the rendering speed (which would be the return immediacy of functions) and found that using this approach would make for blisteringly fast responses from that function.

    First problem is obvious; you cannot thread javascript, so you win nothing here while you add obfuscation. Secondly, you have now effectively detached the rendering of a template from the stack of possible event listeners that might expect that very template to have been rendered, while it may very well not have been. The actual behaviour of that function was now non-deterministic, as was — unknowingly so — any function that would run it, or depend on it. You can make educated guesses, but you cannot properly code for its behaviour.

    The “fix” when writing a new event handler that depended on its logic was to also use setTimeout 0. But, that’s not a fix, it is hard to understand, and it is no fun to debug errors that are caused by code like this. Sometimes there’s no problem ever, other times it concistently fails, and then again, sometimes it works and breaks sporadically, depending on the current performance of the platform and whatever else happens to going on at the time. This is why I personally would advise against using this hack (it is a hack, and we should all know that it is), unless you really know what you’re doing and what the consequences are.

    But what can we do instead? Well, as the referenced MDN article suggests, either split the work into multiple messages (if you can) so that other messages that are queued up may be interleaved with your work and executed while it runs, or use a web worker, which can run in tandem with your page and return results when done with its calculations.

    Oh, and if you’re thinking, “Well, couldn’t I just put a callback in the long-running function to make it asynchronous?,” then no. The callback doesn’t make it asynchronous, it’ll still have to run the long-running code before explicitly calling your callback.

  7. This is an old questions with old answers. I wanted to add a new look at this problem and to answer why is this happens and not why is this useful.

    So you have two functions:

    var f1 = function () { setTimeout(function(){ console.log("f1", "First function call..."); }, 0); }; var f2 = function () { console.log("f2", "Second call..."); }; 

    and then call them in the following order f1(); f2(); just to see that the second one executed first.

    And here is why: it is not possible to have setTimeout with a time delay of 0 milliseconds. The Minimum value is determined by the browser and it is not 0 milliseconds. Historically browsers sets this minimum to 10 milliseconds, but the HTML5 specs and modern browsers have it set at 4 milliseconds.

    If nesting level is greater than 5, and timeout is less than 4, then increase timeout to 4.

    Also from mozilla:

    To implement a 0 ms timeout in a modern browser, you can use window.postMessage() as described here.

    P.S. information is taken after reading the following article.

  8. If you don’t want to watch a whole video, here’s a simple explanation of the things one needs to understand, in order to be able to understand the answer to this question:

    1. JavaScript is single-threaded meaning it does only one thing at a time when running.
    2. But the environments in which the JavaScript is running, can be multi-threaded. E.g., browsers are often multi-threaded creatures, i.e., are able to do multiple things at a time. So they can run JavaScript and at the same time keep track of dealing with other stuff too.

    From this point on, we’re talking about JavaScript “in browsers”. Things like setTimeout are indeed browser things, and are not part of the JavaScript itself.

    1. The thing that allows JavaScript to run asynchronously is the multi-threaded browser! Other than the main space Javascript uses (called the the call stack) to put each line of code on and run them one by one, browsers also provide JavaScript with another space to put things on.

    Now let’s call that other space the second space.

    1. Let’s assume fn is a function. The important thing to understand here is that fn(); call is not equal to the setTimeout(fn, 0); call as will be explained further below.

    Instead of a 0 delay, let’s assume another delay first, e.g., 5000 milliseconds: setTimeout(fn, 5000);. It’s important to note that this is still a “function call”, so it has to be put on the main space, and removed from it when it’s done, but wait!, we don’t like a whole lengthy and boring 5 seconds delay. That would block the main space and will not allow JavaScript to run ANYTHING else in the meantime.

    Thankfully this is not how the browser designers designed them to work. Instead, this call(setTimeout(fn, 5000);) is done instantly. This is very important: Even with the 5000 milliseconds delay, this function call is complete in an instant! What will happen next? It gets removed from the main space. Where will it be put on? (because we don’t want to lose it). You might have guessed right: The browser hears this call and puts it on the second space. enter image description here

    The browser keeps track of the 5 seconds delay and once it’s passed, it looks at the main space, and “WHEN IT’S EMPTY”, puts the fn(); call back on it. That is how the setTimeout works.

    So, back to the setTimeout(fn, 0), even though the delay is zero, this is still a call to the browser, and the browser hears it instantly and picks it up, and puts it on the second space and puts it back on the main space only when the main space is empty again, and not really 0 milliseconds later.

    I really recommend watching that video as well since he’s explained it really well, and opens technical things up more.

  9. Since it is being passed a duration of 0, I suppose it is in order to remove the code passed to the setTimeout from the flow of execution. So if it’s a function that could take a while, it won’t prevent the subsequent code from executing.

  10. The other thing this does is push the function invocation to the bottom of the stack, preventing a stack overflow if you are recursively calling a function. This has the effect of a while loop but lets the JavaScript engine fire other asynchronous timers.

  11. By calling setTimeout you give the page time to react to the whatever the user is doing. This is particularly helpful for functions run during page load.

  12. Some other cases where setTimeout is useful:

    You want to break a long-running loop or calculation into smaller components so that the browser doesn’t appear to ‘freeze’ or say “Script on page is busy”.

    You want to disable a form submit button when clicked, but if you disable the button in the onClick handler the form will not be submitted. setTimeout with a time of zero does the trick, allowing the event to end, the form to begin submitting, then your button can be disabled.

  13. The problem was you were trying to perform a Javascript operation on a non existing element. The element was yet to be loaded and setTimeout() gives more time for an element to load in the following ways:

    1. setTimeout() causes the event to be ansynchronous therefore being executed after all the synchronous code, giving your element more time to load. Asynchronous callbacks like the callback in setTimeout() are placed in the event queue and put on the stack by the event loop after the stack of synchronous code is empty.
    2. The value 0 for ms as a second argument in function setTimeout() is often slightly higher (4-10ms depending on browser). This slightly higher time needed for executing the setTimeout() callbacks is caused by the amount of ‘ticks’ (where a tick is pushing a callback on the stack if stack is empty) of the event loop. Because of performance and battery life reasons the amount of ticks in the event loop are restricted to a certain amount less than 1000 times per second.
  14. The answers about execution loops and rendering the DOM before some other code completes are correct. Zero second timeouts in JavaScript help make the code pseudo-multithreaded, even though it is not.

    I want to add that the BEST value for a cross browser / cross platform zero-second timeout in JavaScript is actually about 20 milliseconds instead of 0 (zero), because many mobile browsers can’t register timeouts smaller than 20 milliseconds due to clock limitations on AMD chips.

    Also, long-running processes that do not involve DOM manipulation should be sent to Web Workers now, as they provide true multithreaded execution of JavaScript.

  15. setTimout on 0 is also very useful in the pattern of setting up a deferred promise, which you want to return right away:

    myObject.prototype.myMethodDeferred = function() { var deferredObject = $.Deferred(); var that = this; // Because setTimeout won't work right with this setTimeout(function() { return myMethodActualWork.call(that, deferredObject); }, 0); return deferredObject.promise(); } 
  16. Javascript is single threaded application so that don’t allow to run function concurrently so to achieve this event loops are use. So exactly what setTimeout(fn, 0) do that its pussed into task quest which is executed when your call stack is empty. I know this explanation is pretty boring, so i recommend you to go through this video this will help you how things work under the hood in browser. Check out this video:- https://www.youtube.com/watch?time_continue=392&v=8aGhZQkoFbQ

  17. Yet another TL;DR

    Iterator on list: next() returns the next element of the list

    Iterator generator: next() will compute the next element on the fly (execute code)

    You can see the yield/generator as a way to manually run the control flow from outside (like continue loop one step), by calling next, however complex the flow.

    Note: The generator is NOT a normal function. It remembers the previous state like local variables (stack). See other answers or articles for detailed explanation. The generator can only be iterated on once. You could do without yield, but it would not be as nice, so it can be considered ‘very nice’ language sugar.

  18. Here’s a simple yield based approach, to compute the fibonacci series, explained:

    def fib(limit=50): a, b = 0, 1 for i in range(limit): yield b a, b = b, a+b 

    When you enter this into your REPL and then try and call it, you’ll get a mystifying result:

    >>> fib() <generator object fib at 0x7fa38394e3b8> 

    This is because the presence of yield signaled to Python that you want to create a generator, that is, an object that generates values on demand.

    So, how do you generate these values? This can either be done directly by using the built-in function next, or, indirectly by feeding it to a construct that consumes values.

    Using the built-in next() function, you directly invoke .next/__next__, forcing the generator to produce a value:

    >>> g = fib() >>> next(g) 1 >>> next(g) 1 >>> next(g) 2 >>> next(g) 3 >>> next(g) 5 

    Indirectly, if you provide fib to a for loop, a list initializer, a tuple initializer, or anything else that expects an object that generates/produces values, you’ll “consume” the generator until no more values can be produced by it (and it returns):

    results = [] for i in fib(30): # consumes fib results.append(i) # can also be accomplished with results = list(fib(30)) # consumes fib 

    Similarly, with a tuple initializer:

    >>> tuple(fib(5)) # consumes fib (1, 1, 2, 3, 5) 

    A generator differs from a function in the sense that it is lazy. It accomplishes this by maintaining it’s local state and allowing you to resume whenever you need to.

    When you first invoke fib by calling it:

    f = fib() 

    Python compiles the function, encounters the yield keyword and simply returns a generator object back at you. Not very helpful it seems.

    When you then request it generates the first value, directly or indirectly, it executes all statements that it finds, until it encounters a yield, it then yields back the value you supplied to yield and pauses. For an example that better demonstrates this, let’s use some print calls (replace with print "text" if on Python 2):

    def yielder(value): """ This is an infinite generator. Only use next on it """ while 1: print("I'm going to generate the value for you") print("Then I'll pause for a while") yield value print("Let's go through it again.") 

    Now, enter in the REPL:

    >>> gen = yielder("Hello, yield!") 

    you have a generator object now waiting for a command for it to generate a value. Use next and see what get’s printed:

    >>> next(gen) # runs until it finds a yield I'm going to generate the value for you Then I'll pause for a while 'Hello, yield!' 

    The unquoted results are what’s printed. The quoted result is what is returned from yield. Call next again now:

    >>> next(gen) # continues from yield and runs again Let's go through it again. I'm going to generate the value for you Then I'll pause for a while 'Hello, yield!' 

    The generator remembers it was paused at yield value and resumes from there. The next message is printed and the search for the yield statement to pause at it performed again (due to the while loop).

  19. yield is similar to return. The difference is:

    yield makes a function iterable (in the following example primes(n = 1) function becomes iterable).
    What it essentially means is the next time the function is called, it will continue from where it left (which is after the line of yield expression).

    def isprime(n): if n == 1: return False for x in range(2, n): if n % x == 0: return False else: return True def primes(n = 1): while(True): if isprime(n): yield n n += 1 for n in primes(): if n > 100: break print(n) 

    In the above example if isprime(n) is true it will return the prime number. In the next iteration it will continue from the next line

    n += 1 
  20. In Python generators (a special type of iterators) are used to generate series of values and yield keyword is just like the return keyword of generator functions.

    The other fascinating thing yield keyword does is saving the state of a generator function.

    So, we can set a number to a different value each time the generator yields.

    Here’s an instance:

    def getPrimes(number): while True: if isPrime(number): number = yield number # a miracle occurs here number += 1 def printSuccessivePrimes(iterations, base=10): primeGenerator = getPrimes(base) primeGenerator.send(None) for power in range(iterations): print(primeGenerator.send(base ** power)) 
  21. In [4]: def make_cake(numbers): ...: for i in range(numbers): ...: yield 'Cake {}'.format(i) ...: In [5]: factory = make_cake(5)
  22. All of the answers here are great; but only one of them (the most voted one) relates to how your code works. Others are relating to generators in general, and how they work.

    So I won’t repeat what generators are or what yields do; I think these are covered by great existing answers. However, after spending few hours trying to understand a similar code to yours, I’ll break it down how it works.

    Your code traverse a binary tree structure. Let’s take this tree for example:

     5 /  3 6 /   1 4 8 

    And another simpler implementation of a binary-search tree traversal:

    class Node(object): .. def __iter__(self): if self.has_left_child(): for child in self.left: yield child yield self.val if self.has_right_child(): for child in self.right: yield child 

    The execution code is on the Tree object, which implements __iter__ as this:

    def __iter__(self): class EmptyIter(): def next(self): raise StopIteration if self.root: return self.root.__iter__() return EmptyIter() 

    The while candidates statement can be replaced with for element in tree; Python translate this to

    it = iter(TreeObj) # returns iter(self.root) which calls self.root.__iter__() for element in it: .. process element .. 

    Because Node.__iter__ function is a generator, the code inside it is executed per iteration. So the execution would look like this:

    1. root element is first; check if it has left childs and for iterate them (let’s call it it1 because its the first iterator object)
    2. it has a child so the for is executed. The for child in self.left creates a new iterator from self.left, which is a Node object itself (it2)
    3. Same logic as 2, and a new iterator is created (it3)
    4. Now we reached the left end of the tree. it3 has no left childs so it continues and yield self.value
    5. On the next call to next(it3) it raises StopIteration and exists since it has no right childs (it reaches to the end of the function without yield anything)
    6. it1 and it2 are still active – they are not exhausted and calling next(it2) would yield values, not raise StopIteration
    7. Now we are back to it2 context, and call next(it2) which continues where it stopped: right after the yield child statement. Since it has no more left childs it continues and yields it’s self.val.

    The catch here is that every iteration creates sub-iterators to traverse the tree, and holds the state of the current iterator. Once it reaches the end it traverse back the stack, and values are returned in the correct order (smallest yields value first).

    Your code example did something similar in a different technique: it populated a one-element list for every child, then on the next iteration it pops it and run the function code on the current object (hence the self).

    I hope this contributed a little to this legendary topic. I spent several good hours drawing this process to understand it.

  23. The yield keyword in Python used to exit from the code without disturbing the state of local variables and when again the function is called the execution starts from the last point where we left the code.

    The below example demonstrates the working of yield:

    def counter(): x=2 while x < 5: yield x x += 1 print("Initial value of x: ", counter()) for y in counter(): print(y) 

    The above code generates the Below output:

    Initial value of x: <generator object counter at 0x7f0263020ac0> 2 3 4 
  24. Can also send data back to the generator!

    Indeed, as many answers here explain, using yield creates a generator.

    You can use the yield keyword to send data back to a “live” generator.


    Let’s say we have a method which translates from english to some other language. And in the beginning of it, it does something which is heavy and should be done once. We want this method run forever (don’t really know why.. :)), and receive words words to be translated.

    def translator(): # load all the words in English language and the translation to 'other lang' my_words_dict = {'hello': 'hello in other language', 'dog': 'dog in other language'} while True: word = (yield) yield my_words_dict.get(word, 'Unknown word...') 


    my_words_translator = translator() next(my_words_translator) print(my_words_translator.send('dog')) next(my_words_translator) print(my_words_translator.send('cat')) 

    will print:

    dog in other language Unknown word... 

    To summarise:

    use send method inside a generator to send data back to the generator. To allow that, a (yield) is used.

  25. yield in python is in a way similar to the return statement, except for some differences. If multiple values have to be returned from a function, return statement will return all the values as a list and it has to be stored in the memory in the caller block. But what if we don’t want to use extra memory? Instead, we want to get the value from the function when we need it. This is where yield comes in. Consider the following function :-

    def fun(): yield 1 yield 2 yield 3 

    And the caller is :-

    def caller(): print ('First value printing') print (fun()) print ('Second value printing') print (fun()) print ('Third value printing') print (fun()) 

    The above code segment (caller function) when called, outputs :-

    First value printing 1 Second value printing 2 Third value printing 3 

    As can be seen from above, yield returns a value to its caller, but when the function is called again, it doesn’t start from the first statement, but from the statement right after the yield. In the above example, “First value printing” was printed and the function was called. 1 was returned and printed. Then “Second value printing” was printed and again fun() was called. Instead of printing 1 (the first statement), it returned 2, i.e., the statement just after yield 1. The same process is repeated further.

  26. Simple answer

    When function contains at least one yield statement, the function automaticly becomes generator function. When you call generator function, python executes code in the generator function until yield statement occur. yield statement freezes the function with all its internal states. When you call generator function again, python continues execution of code in the generator function from frozen position, until yield statement occur again and again. The generator function executes code until generator function runs out without yield statement.


    Create a list and return it:

    def my_range(n): my_list = [] i = 0 while i < n: my_list.append(i) i += 1 return my_list @profile def function(): my_sum = 0 my_values = my_range(1000000) for my_value in my_values: my_sum += my_value function() 

    Results with:

    Total time: 1.07901 s Timer unit: 1e-06 s Line # Hits Time Per Hit % Time Line Contents ============================================================== 9 @profile 10 def function(): 11 1 1.1 1.1 0.0 my_sum = 0 12 1 494875.0 494875.0 45.9 my_values = my_range(1000000) 13 1000001 262842.1 0.3 24.4 for my_value in my_values: 14 1000000 321289.8 0.3 29.8 my_sum += my_value Line # Mem usage Increment Occurences Line Contents ============================================================ 9 40.168 MiB 40.168 MiB 1 @profile 10 def function(): 11 40.168 MiB 0.000 MiB 1 my_sum = 0 12 78.914 MiB 38.746 MiB 1 my_values = my_range(1000000) 13 78.941 MiB 0.012 MiB 1000001 for my_value in my_values: 14 78.941 MiB 0.016 MiB 1000000 my_sum += my_value 

    Generate values on the fly:

    def my_range(n): i = 0 while i < n: yield i i += 1 @profile def function(): my_sum = 0 for my_value in my_range(1000000): my_sum += my_value function() 

    Results with:

    Total time: 1.24841 s Timer unit: 1e-06 s Line # Hits Time Per Hit % Time Line Contents ============================================================== 7 @profile 8 def function(): 9 1 1.1 1.1 0.0 my_sum = 0 10 11 1000001 895617.3 0.9 71.7 for my_value in my_range(1000000): 12 1000000 352793.7 0.4 28.3 my_sum += my_value Line # Mem usage Increment Occurences Line Contents ============================================================ 7 40.168 MiB 40.168 MiB 1 @profile 8 def function(): 9 40.168 MiB 0.000 MiB 1 my_sum = 0 10 11 40.203 MiB 0.016 MiB 1000001 for my_value in my_range(1000000): 12 40.203 MiB 0.020 MiB 1000000 my_sum += my_value 


    The generator function needs a little more time to execute, than function which returns a list but it use much less memory.

  27. A simple use case:

    >>> def foo(): yield 100 yield 20 yield 3 >>> for i in foo(): print(i) 100 20 3 >>>  

    How it works: when called, the function returns an object immediately. The object can be passed to the next() function. Whenever the next() function is called, your function runs up until the next yield and provides the return value for the next() function.

    Under the hood, the for loop recognizes that the object is a generator object and uses next() to get the next value.

    In some languages like ES6 and higher, it’s implemented a little differently so next is a member function of the generator object, and you could pass values from the caller every time it gets the next value. So if result is the generator then you could do something like y = result.next(555), and the program yielding values could say something like z = yield 999. The value of y would be 999 that next gets from the yield, and the value of z would be 555 that yield gets from the next. Python get and send methods have a similar effect.

  28. Usually, it’s used to create an iterator out of function. Think ‘yield’ as an append() to your function and your function as an array. And if certain criteria meet, you can add that value in your function to make it an iterator.

    arr=[] if 2>0: arr.append(2) def func(): if 2>0: yield 2 

    the output will be the same for both.

    The main advantage of using yield is to creating iterators. Iterators don’t compute the value of each item when instantiated. They only compute it when you ask for it. This is known as lazy evaluation.

  29. Generators allow to get individual processed items immediately (without the need to wait for the whole collection to be processed). This is illustrated in the example below.

    import time def get_gen(): for i in range(10): yield i time.sleep(1) def get_list(): ret = [] for i in range(10): ret.append(i) time.sleep(1) return ret start_time = time.time() print('get_gen iteration (individual results come immediately)') for i in get_gen(): print(f'result arrived after: {time.time() - start_time:.0f} seconds') print() start_time = time.time() print('get_list iteration (results come all at once)') for i in get_list(): print(f'result arrived after: {time.time() - start_time:.0f} seconds') 
    get_gen iteration (individual results come immediately) result arrived after: 0 seconds result arrived after: 1 seconds result arrived after: 2 seconds result arrived after: 3 seconds result arrived after: 4 seconds result arrived after: 5 seconds result arrived after: 6 seconds result arrived after: 7 seconds result arrived after: 8 seconds result arrived after: 9 seconds get_list iteration (results come all at once) result arrived after: 10 seconds result arrived after: 10 seconds result arrived after: 10 seconds result arrived after: 10 seconds result arrived after: 10 seconds result arrived after: 10 seconds result arrived after: 10 seconds result arrived after: 10 seconds result arrived after: 10 seconds result arrived after: 10 seconds 
  30. The yield keyword is used in enumeration/iteration where the function is expected to return more then one output. I want to quote this very simple example A:

    # example A def getNumber(): for r in range(1,10): return r 

    The above function will return only 1 even when it’s called multiple times. Now if we replace return with yield as in example B:

    # example B def getNumber(): for r in range(1,10): yield r 

    It will return 1 when first called 2 when called again then 3,4 and it goes to increment till 10.

    Although the example B is conceptually true but to call it in python 3 we have to do the following:

     g = getNumber() #instance print(next(g)) #will print 1 print(next(g)) #will print 2 print(next(g)) #will print 3 # so to assign it to a variables v = getNumber() v1 = next(v) #v1 will have 1 v2 = next(v) #v2 will have 2 v3 = next(v) #v3 will have 3 
  31. names = ['Sam', 'Sarah', 'Thomas', 'James'] # Using function def greet(name) : return f'Hi, my name is {name}.' for each_name in names: print(greet(each_name)) # Output: >>>Hi, my name is Sam. >>>Hi, my name is Sarah. >>>Hi, my name is Thomas. >>>Hi, my name is James. # using generator def greetings(names) : for each_name in names: yield f'Hi, my name is {each_name}.' for greet_name in greetings(names): print (greet_name) # Output: >>>Hi, my name is Sam. >>>Hi, my name is Sarah. >>>Hi, my name is Thomas. >>>Hi, my name is James.
  32. Key points

    • The grammar for Python uses the presence of the yield keyword to make a function that returns a generator.

    • A generator is a kind of iterator, which is that main way that looping occurs in Python.

    • A generator is essentially a resumable function. Unlike return that returns a value and ends a function, the yield keyword returns a value and suspends a function.

    • When next(g) is called on a generator, the function resumes execution where it left off.

    • Only when the function encounters an explicit or implied return does it actually end.

    Technique for writing and understanding generators

    An easy way to understand and think about generators is to write a regular function with print() instead of yield:

    def f(n): for x in range(n): print(x) print(x * 10) 

    Watch what it outputs:

    >>> f(3) 0 0 1 10 2 2 

    When that function is understood, substitute the yield for print to get a generator that produces the same values:

    def f(n): for x in range(n): yield x yield x * 10 

    Which gives:

    >>> list(f(3)) [0, 0, 1, 10, 2, 20] 

    Iterator protocol

    The answer to “what yield does” can be short and simple, but it is part of a larger world, the so-called “iterator protocol”.

    On the sender side of iterator protocol, there are two relevant kinds of objects. The iterables are things you can loop over. And the iterators are objects that track the loop state.

    On the consumer side of the iterator protocol, we call iter() on the iterable object to get a iterator. Then we call next() on the iterator to retrieve values from the iterator. When there is no more data, a StopIteration exception is raised:

    >>> s = [10, 20, 30] # The list is the "iterable" >>> it = iter(s) # This is the "iterator" >>> next(it) # Gets values out of an iterator 10 >>> next(it) 20 >>> next(it) 30 >>> next(it) Traceback (most recent call last): ... StopIteration 

    To make this all easier for us, for-loops call iter and next on our behalf:

    >>> for x in s: ...  print(x) ...  10 20 30 

    A person could write a book about all this, but these are the key points. When I teach Python courses, I’ve found that this is a minimal sufficient explanation to build understand and start using it right away. In particular, the trick of writing a function with print, testing it, and then converting to yield seems to work well with all levels of Python programmers.

  33. To understand its yield function, one must understand what a generator is. Moreover, before understanding generators, you must understand iterables. Iterable: iterable To create a list, you naturally need to be able to read each element one by one. The process of reading its items one by one is called iteration:

    >>> mylist = [1, 2, 3] >>> for i in mylist: ...  print(i) 1 2 3 

    mylist is an iterable. When you use list comprehensions, you create a list and therefore iterable:

    >>> mylist = [x*x for x in range(3)] >>> for i in mylist: ...  print(i) 0 1 4 

    All data structures that can be used for… in… are iterable; lists, strings, files…

    These iterable methods are convenient because you can read them at will, but you store all the values ​​in memory, which is not always desirable when you have many values. Generator: generator A generator is also a kind of iterator, a special kind of iteration, which can only be iterated once. The generator does not store all values ​​in memory, but generates values ​​on the fly:

    generator: generator, generator, generator generates electricity but does not store energy;)

    >>> mygenerator = (x*x for x in range(3)) >>> for i in mygenerator: ...  print(i) 0 1 4 

    As long as () is used instead of [], the list comprehension becomes the generator comprehension. However, since the generator can only be used once, you cannot execute for i in mygenerator a second time: the generator calculates 0, then discards it, then calculates 1, and the last time it calculates 4. The typical black blind man breaks corn.

    The yield keyword is used in the same way as return, except that the function will return the generator.

    >>> def createGenerator(): ...  mylist = range(3) ...  for i in mylist: ...  yield i*i ... >>> mygenerator = createGenerator() >>> print(mygenerator) <generator object createGenerator at 0xb7555c34> >>> for i in mygenerator: ...  print(i) 0 1 4 

    This example itself is useless, but when you need a function to return a large number of values ​​and only need to read it once, using yield becomes convenient.

    To master the yield, one need to be clear is that when a function is called, the code written in the function body will not run. The function only returns the generator object. Beginners are likely to be confused about this.

    Second, understand that the code will continue from where it left off every time for uses the generator.

    The most difficult part now is:

    The first time for calls the generator object created from your function, it will run the code in the function from the beginning until it hits yield, and then it will return the first value of the loop. Then, each subsequent call will run the next iteration of the loop you wrote in the function and return the next value. This will continue until the generator is considered empty, which yields when there is no hit while the function is running. That may be because the loop has ended, or because you are no longer satisfied with “if/else”.

    Personal understanding I hope to help you!

Tasg: javascript, dom