[prog] Converting definitions into 'on the fly' code... And GPL query

[Rasjid Wilcox]

On Friday 14 May 2004 20:26, Conor Daly wrote:
> On Fri, May 14, 2004 at 08:00:20PM +1000 or thereabouts, Rasjid Wilcox 
wrote:
> > On Thursday 13 May 2004 23:51, Conor Daly wrote:
> > > I've spent the last 4 days hacking on this in an attempt to understand
> > > it and I think I've got it now.  Looks pretty damn good to me.  I
> > > haven't figured out yet how the self.equation bit works yet (it does, I
> > > just don't know how...).  I'm going off to present this as a sample to
> > > the project leader now.
>
> Who was mightily impressed...
>
> > You are more than welcome to ask questions.
> >
> > Also, if you have not worked out how to read the index table only once
> > (at class initialisation time) rather than for each record, let me know. 
> > It should only be around a 5 line change, and pretty simple.
>
> Chances are we will end up using a temporary (or should I say
> non-permanent) table containing a data 'heap'.  This will likely end up
> with columns named to correspond to the variable names in the equations.

Ah.  I see what you mean.  Yes, that is another way of dealing with the 
problem.

This actually brings it much closer to the original form of the code - I 
started work on a database report writing tool using ReportLab as the 
'low-level' output engine, and was using the approach to give my 'report 
definition files' formula calculations 'for free' so to speak.  I'll get back 
to that project one day soon(tm).

> > Lastly, did you note the change I made to allow the use of mutli-line
> > tests that can utilise their own variables?  It makes the system
> > substantially more powerful and flexible, without making it any more
> > complex for the current case.  (Current style tests are just prefixed
> > with 'result = '.)
>
> I saw but wasn't quite clear on how it's used.  In any case, this is
> currently a prototype sample and will be significantly refined before
> production.

It makes it very close to how you can define boolean 'tests' in Crystal 
Reports.  You have an entire programming language (with some pre-defined 
constructs and known variables) to be utilised it determining the final 
boolean result.

Also, see below.

> One thing that came to mind was:  "What if the minute data is missing?".
> Currently the _sumOverDate() function returns 0 if there's no data.  Can
> one return NULL or some other something that will cause
> 'eval(self.equation)' to return false?  The instance could arise where 'rrr
> - _sumOverDate('r', 'minute'...)' will have a valid rrr=0 and
> _sumOverDate() return 0 'cos there's no data so the eval() will return true
> which would be an error.

A case in point; this is where the more generalised 'exec' form would come in 
useful.

Suppose you change someOverDate() so that it returns 'None' if no data is 
found.  (A good idea, I only did not do so to keep things simple.)

Then the test could be:

minuteSum = sumOverDate('r', 'minute', hour, -1, 0)
if minuteSum == None:
    result = False
else:
    result = (abs(rrr - minutesum) < 0.001)

> That lead to a discussion on whether the tests should know whether there
> should be a particular data set (eg. some stations report only hourly
> rainfall so there'll be no minute rain from them) and should return a
> 'pass' instead of a 'fail'.  My view is that the program should decide
> whether it's appropriate for a particular test to run ("should we have
> minute rain?"  "Do we have minute rain?" ...) rather than the test itself.

This is a fairly fundamential design decision.  Where do you want the 
'intelligence' required for the tests.  One approach (which requires the 
'exec' form) is that the core program *only* provides a set of standard 
functions and the framework for building tests.  All the 'smarts' are in the 
tests themselves.  In this case, once well established and tested, the core 
system could potentially remain untouched regardless of new tests and data 
being set up.

If the core program decides what to run, then it has to be adjusted to 'know' 
about what tests do what, rather than just being told 'run all tests in file 
foo', and the test itself working out if it should be run (and declining if 
inappropriate).

However, provided you structure the core program in a clear way it is somewhat 
academic given that it is all Python anyway.

Personally I would have all the 'smarts' to do with the test in the one place, 
and add another property to the 'Test' class which would be instance specific 
code (ie, different for each 'Test' instance) that would check to see if this 
particular test should be run for this particular station.

> The other interesting licensing question is in the other direction.
> Assuming I have released a GPL application.  Someone wants to use it but in
> a proprietary application which the GPL won't allow.  They contact me and
> ask to license my application to them for proprietary use.  Can I construct
> a license that requires them to:
>
> o Acknowledge the existence of code that is also available under GPL
> o Provide the standard GPL 'offer of source' for my code
> without having to GPL their proprietary extensions.  Of course I can, but
> is it in any way useful for me to do this?

Sounds rather like the LGPL to me.

Cheers,

Rasjid.

-- 
Rasjid Wilcox
Canberra, Australia (UTC +10 hrs)
http://www.openminddev.net