Re: recursion limit
nicky van foreest <[email protected]> Sat, 16 Jul 2011 22:43:23 +0200
| Newsgroups | gmane.comp.python.peak |
|---|---|
| Message-ID | <CAK_GA2F2WLh=JpsvC-6ypCW45YmNkRRb1wdKYanB5bc2_948Xw@mail.gmail.com> |
HI Philip, Thanks for your explanations. > Ok, confirmed at 100, and switching the 'compute' attrs to 'maintain' attrs > makes it go away, even up to 10000. Here it also works at 10000 too, but it becomes noticebly slow. However, this is as expected, given the amount of work. > Cell objects have a level attribute that's used to indicate their distance > from a dependency graph root; is that what you're asking about? Yes. > > >> Second, I would like to have a >> program/parser that figures out by itself the dependency graph of the >> attributes and functions. Now I have to make explicit the >> trellis.attrs and the trellis.compute.attrs/trellis.maintain.attrs, >> which I would prefer not to do by hand, but let the computer figure it >> out. Why is this is not implemented in trellis? (I must admit that I >> don't quite know how to do this; it is just a question out of >> interest.) > > I don't understand what feature you're asking for here. The distinction > between compute, maintain, and attrs is part of the design of your program, > not something that a parser can figure out. By stating that something is a > maintained value, it means that it may have side-effects and also that it > should be able to access the previously computed value. By saying it's > computed, you are saying there are no side-effects to the computation and > that it should only be calculated as needed. Otherwise, it is just an > observable variable. Ok. I did not understand this distinction well enough up to now, at least not in the sense that this distinction can (and should) be used as a part of the design of a program. Nicky