Avoid source manip with decorators

Opening this per @maxpumperla suggestion on twitter. A little pie in the sky suggestion, forgive me. I noticed the template mechanism and I went to look at the implementation, getsource and related. How robust is that manipulation? Can I pass a variable or a complex expression in between double curly brackets? Can’t it be confused with a set of sets (which is not allowed in python, but still that’s what a {{x}} tries to evaluate to. My point is that you don’t really need a language extension, if I get it right. You need to call model.fit many times with different values for the parameters. This is also done in randomized testing and in python in particular in the package hypothesis. If you have a function f(x,y) you want to run on random inputs you just need to write

from hypothesis import given
from hypothesis.strategies import integers, booleans
@given(x = integers(), y = booleans())
def f(x,y):

will make f into a 0 non-default argument function that can just be called as f() and will run f(x,y) multiple times with random inputs. So I thought why not apply the same approach to hyperas to write something like

@optimize(dropout  = uniform(0,1), shape = choice([256, 512, 1024]))
def opt(dropout, shape):
return Sequential(
 ...
 Dropout(dropout = dropout))

The decorator just samples the parameters from the distribution, creates and fits as many models as necessary and computes summary stats. It may be a little more verbose then the {{}} notation and I am all for brevity, but doesn’t tamper with Python’s evaluation mechanism. In the spirit of least surprise and least effort, why not use a decorator? I may be missing the fundamental reason to use {{}}, but then it’s good to have it written down for posterity. Thanks

[maxpumperla]

dude, I really don’t think you get it. I get 100+ github notifications per day, of course I have to rely on certain things, otherwise I would go crazy. Doesn’t mean I neglect things on purpose. Apart from a day job and a family, you think your regular open source monkey would do everything to comb through tickets post-closure? think again.

Wait, I need to educate ppl on this? If people necro in tickets without bothering about the context, clarifying or suggesting to reopen it, that is hardly my fault and not how the ticket system should be used. I just went quickly through the thread yesterday to assess your position, otherwise I was unaware of this. I can tell you from experience, there’s a ton of maintainers who would take a “build is green, rtfm” view on this one.

you may differ all you want and that’s fine with me, but at the very least be polite, produce meaningful issues and be constructive about it. it’s very easy to load it all off on someone else. talk is cheap.

[piccolbo]

No sorry, life is not cooperating. Will get back to you.