Fair enough. I had perhaps wrongly assumed that since Christian wanted to figure out the type of his expression's result, he must have differently typed database columns (or whatever) for different types of result. Best regards all round.

Vernon Cole wrote:
Stephen said what I was trying to say. It does not matter what the user sends you, you must try to coerce his result into something the database will accept. This is most easily done dynamically at run time. Also forgive my typo of "impert" for "import" ... I reread my answer three times and still missed it.
--
Vernon Cole

On Mon, Oct 19, 2009 at 8:29 AM, Lepisto, Stephen P <[email protected] <mailto:[email protected]>> wrote:

    Jonathan,

    Even if the variables going into the expression are strongly
    typed, python will evaluate the expression however it can, with
    the result being some type based on the coercion python applied to
    each variable.  However, I read Christian's problem as one where
    he needed to get the value into a database and to me that was the
    deciding factor as to which type to coerce the result of the
    expression, regardless of the original types of the variables
    going into the expression.


    -----Original Message-----
    From: [email protected]
    <mailto:[email protected]>
    [mailto:[email protected]
    <mailto:[email protected]>] On Behalf Of Jonathan
    Hartley
    Sent: Monday, October 19, 2009 7:19 AM
    To: Discussion of IronPython
    Subject: Re: [IronPython] Type analysis of expression

    Hey all,
    Stephen, I infer that Christian can't evaluate the expression yet. (If
    he could, then deriving the type of the result would be trivial)
    Presumably the variables in the expression don't yet have known
    values.

    So he has an expression which cannot be evaluated, but he wants to
    guess
    what type the return value would be if the variables in the expression
    were known.

    The variables in the expression do have known types. So I wonder
    if you
    could pick a prototypical value for each variable, (eg. set all floats
    to 1.0, and all integers to 1) and then evaluate the expression to see
    what type the result is?

    Obviously this won't work for all expressions (eg. "x / (x - 1)"), but
    maybe it would work enough of the time, depending on what form your
    expressions take.

    Am I misunderstanding entirely, or only partially?

       Jonathan

    Lepisto, Stephen P wrote:
    > What about treating the return type of the python expression as
    object then coerce the object into the type required by the
    database?  If the coercion fails, then that could be treated as a
    type error.
    >
    > For example, after using python to evaluate the expression
    '2+(4*5)', the returned object could be converted to an integer
    using System.Convert.ToInt32() or to a string with
    System.Convert.ToString().  System.Convert throws
    InvalidCastException for those cases that cannot be converted.
    >
    >
    > -----Original Message-----
    > From: [email protected]
    <mailto:[email protected]>
    [mailto:[email protected]
    <mailto:[email protected]>] On Behalf Of Michael
    Foord
    > Sent: Monday, October 19, 2009 4:21 AM
    > To: Discussion of IronPython
    > Subject: Re: [IronPython] Type analysis of expression
    >
    > Christian Schmidt wrote:
    >
    >> Hello,
    >>
    >> we are using IronPython embedded into our application to
    evaluate user
    >> defined expression. The "variables" used in the expressions are
    strongly
    >> typed and the results need to be written back into a database.
    >>
    >> I know that the return type of a dynamic expression cannot be
    determined
    >> in general. But what would be a pragmatic way to guess the
    return type
    >> of an expression?
    >>
    >
    > Hehe. If you're evaluating arbitrary functions provided by the
    user then
    > I don't know of any way of 'inferring' the return type - beyond
    parsing
    > it and modelling the type flow through the expression (which
    would be a
    > lot of work).
    >
    > All the best,
    >
    > Michael
    >
    >> Thanks,
    >> Christian
    >>
    >>
    >>
    >> _______________________________________________
    >> Users mailing list
    >> [email protected] <mailto:[email protected]>
    >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
    >>
    >
    >
    >

    --
    Jonathan Hartley      Made of meat.      http://tartley.com
    [email protected] <mailto:[email protected]>   +44 7737 062
    225   twitter/skype: tartley


    _______________________________________________
    Users mailing list
    [email protected] <mailto:[email protected]>
    http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
    _______________________________________________
    Users mailing list
    [email protected] <mailto:[email protected]>
    http://lists.ironpython.com/listinfo.cgi/users-ironpython.com


------------------------------------------------------------------------

_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

--
Jonathan Hartley      Made of meat.      http://tartley.com
[email protected]   +44 7737 062 225   twitter/skype: tartley


_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to