nathan binkert wrote: >> I believe what Gabe is suggesting is switching e.g. Param.String(...) >> to Param(String, ...). This would make it trivial to support >> parameters that reference objects in other modules, e.g.: >> Param(Foo.Bar.Baz, ...) >> (not that it couldn't be done with the current structure, but it >> wouldn't be so trivial). >> >> I guess the question is whether the standard Python class name lookup >> works for param types... the key thing we get with Param.String is >> complete control over that process. >> >> OK, after actually looking at the code, it's partially coming back to >> me; with Param.Foo we defer the lookup of Foo until later, though I >> still don't recall why that was necessary... perhaps to enable >> circular references? Is there a way to handle circular class >> references in Python? > Right. I don't believe there is an easy way to do circular references > in python at the class level. This isn't generally a problem because > the circular reference would usually happen in a def block within the > class and the variables aren't evaluated until the function is > actually called which would usually happen after the whole file is > read in. > > Nate > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev
Are instances of class objects uniquely identifiable and usable as keys? If so, you could use the class as a key using the same mechanism instead of the string name with Param.blah. So then you use class Foo to look up a param description rather than actually doing something fancy with Foo itself. I don't quite follow the subtleties of what you guys are talking about so I'm not sure if that helps. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
