On Sun, 2 Oct 2016 00:55:05 -0700 (PDT) "Edward K. Ream" <[email protected]> wrote:
> Here is the checkin log, slightly modified: > > Fixed a bug in *all *of Leo's generators that return positions, and > added unit tests for the same. > > All of Leo's generator now yield p.copy() instead of p. This makes > the generators much more robust. > > The unit test essentially assert the following: > > len(list(set(any_generator))) == len(list(any_generator)) > > All such assertions failed before the fixes. > > It is *absolutely amazing* that these bugs did not cause more damage. I suspect that they probably did mess people around a bit, but then the docs. explain the need to use .copy(), so just realize they're "doing it wrong", and use .copy(). They weren't exactly bugs, but as you say, the new way's much more robust. The old way seems like it might have been faster for searching etc. - but maybe that's premature optimization. Cheers -Terry > They will bite whenever a script modifies any position returned by a > generator. > > Example 1: Previously, the following failed in mysterious ways. p.v > became None unexpectedly: > > for p in c.all_positions(): > for p in p.children(): > whatever > > This bit me when working on the new mod_http code. > > Example 2: Previously, this failed badly: > > list(g.all_positions()] > > In fact, p.v will be None in all items of the list! > > *Important*: the "extra" calls to p.copy() don't matter: In most > cases, the GC will immediate collect the generated positions. > > Anyway, there is no real alternative. Copying positions eliminates > the possibility for subtle bugs. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
