From jdhardy at gmail.com Mon Oct 19 02:40:57 2009 From: jdhardy at gmail.com (Jeff Hardy) Date: Sun, 18 Oct 2009 18:40:57 -0600 Subject: [IronPython] Wildcard conf on IIS6 In-Reply-To: <20091018105234.GB22055@nysv.org> References: <20091009192947.GJ17007@nysv.org> <20091018105234.GB22055@nysv.org> Message-ID: 2009/10/18 Markus T?rnqvist : >>I finally got around to looking at this, and it looks like I missed a >>step in my documentation (such as it is...). If you check out >>http://jdhardy.blogspot.com/2009/07/nwsgi-20-removing-url-warts.html >>it gives all of the details (under the heading "Wildcards"), but I'll >>explain it here too. > > I had found that by myself too, I based my conf on it ;) I updated it just recently, as there were some omissions. > > I'm wondering about > ? ? > What does ~ resolve to here? The root of the web application - it's an ASP.NET convention. If http://example.com/HelloWorld/ is an ASP.NET application that is stored C:\HelloWorld\, then http://example.com/HelloWorld/hello.wsgi -> ~/hello.wsgi -> C:\HelloWorld\hello.wsgi. Using ~/... allows the app's folders to be moved around the file system without breaking the configuration. > > The Hello World stuff: > > Now http://localhost/ works as well, hooray! So you were able to get the HelloWorld app to work using wildcards, correct? > > But where is the fail? I think this is going to take some deeper digging - do you know how to get a metabase.xml file? Can you send me a copy of yours directly (off-list)? - Jeff From christian2.schmidt at gmx.de Mon Oct 19 09:03:54 2009 From: christian2.schmidt at gmx.de (Christian Schmidt) Date: Mon, 19 Oct 2009 09:03:54 +0200 Subject: [IronPython] Type analysis of expression Message-ID: <4ADC0F5A.8010809@gmx.de> 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? Thanks, Christian From mjt at nysv.org Mon Oct 19 09:19:27 2009 From: mjt at nysv.org (Markus =?iso-8859-1?Q?T=F6rnqvist?=) Date: Mon, 19 Oct 2009 10:19:27 +0300 Subject: [IronPython] Wildcard conf on IIS6 In-Reply-To: References: <20091009192947.GJ17007@nysv.org> <20091018105234.GB22055@nysv.org> Message-ID: <20091019071927.GO22055@nysv.org> On Sun, Oct 18, 2009 at 06:40:57PM -0600, Jeff Hardy wrote: >> The Hello World stuff: > >> Now http://localhost/ works as well, hooray! > >So you were able to get the HelloWorld app to work using wildcards, correct? That would be stretching the term... Like I said in the original post, I got it working under / but not eg. /test/ or /foo/ which would be truly wildcard. Did URLs like that work anywhere else? >> But where is the fail? >I think this is going to take some deeper digging - do you know how to >get a metabase.xml file? Can you send me a copy of yours directly >(off-list)? I don't, but if you tell me, I'd be happy to oblige :) Thanks! -- mjt From empirebuilder at gmail.com Mon Oct 19 10:09:14 2009 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Mon, 19 Oct 2009 10:09:14 +0200 Subject: [IronPython] Wildcard conf on IIS6 In-Reply-To: <20091019071927.GO22055@nysv.org> References: <20091009192947.GJ17007@nysv.org> <20091018105234.GB22055@nysv.org> <20091019071927.GO22055@nysv.org> Message-ID: <8cd017b80910190109j5da7ef4rf65934bd5db38be@mail.gmail.com> MetaBase.xml and MBSchema.xml. IIS stores these files in the *systemroot*\System32\Inetsrv folder of your computer 2009/10/19 Markus T?rnqvist > On Sun, Oct 18, 2009 at 06:40:57PM -0600, Jeff Hardy wrote: > > >> The Hello World stuff: > > > >> Now http://localhost/ works as well, hooray! > > > >So you were able to get the HelloWorld app to work using wildcards, > correct? > > That would be stretching the term... > > Like I said in the original post, I got it working under / but > not eg. /test/ or /foo/ which would be truly wildcard. > > Did URLs like that work anywhere else? > > >> But where is the fail? > >I think this is going to take some deeper digging - do you know how to > >get a metabase.xml file? Can you send me a copy of yours directly > >(off-list)? > > I don't, but if you tell me, I'd be happy to oblige :) > > Thanks! > > -- > mjt > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjt at nysv.org Mon Oct 19 12:09:24 2009 From: mjt at nysv.org (Markus =?iso-8859-1?Q?T=F6rnqvist?=) Date: Mon, 19 Oct 2009 13:09:24 +0300 Subject: [IronPython] Wildcard conf on IIS6 In-Reply-To: <8cd017b80910190109j5da7ef4rf65934bd5db38be@mail.gmail.com> References: <20091009192947.GJ17007@nysv.org> <20091018105234.GB22055@nysv.org> <20091019071927.GO22055@nysv.org> <8cd017b80910190109j5da7ef4rf65934bd5db38be@mail.gmail.com> Message-ID: <20091019100924.GQ22055@nysv.org> On Mon, Oct 19, 2009 at 10:09:14AM +0200, Dody Gunawinata wrote: > MetaBase.xml and MBSchema.xml. IIS stores these files in the >*systemroot*\System32\Inetsrv >folder of your computer Cool! Is there anything specific I should be on the lookout for? -- mjt From fuzzyman at voidspace.org.uk Mon Oct 19 13:20:36 2009 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 19 Oct 2009 12:20:36 +0100 Subject: [IronPython] Type analysis of expression In-Reply-To: <4ADC0F5A.8010809@gmx.de> References: <4ADC0F5A.8010809@gmx.de> Message-ID: <4ADC4B84.6090505@voidspace.org.uk> 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 > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From stephen.p.lepisto at intel.com Mon Oct 19 16:08:26 2009 From: stephen.p.lepisto at intel.com (Lepisto, Stephen P) Date: Mon, 19 Oct 2009 07:08:26 -0700 Subject: [IronPython] Type analysis of expression In-Reply-To: <4ADC4B84.6090505@voidspace.org.uk> References: <4ADC0F5A.8010809@gmx.de> <4ADC4B84.6090505@voidspace.org.uk> Message-ID: <6AF28EB9F93A354894F2F3916DF6F96E0C82C4DAD9@orsmsx510.amr.corp.intel.com> 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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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 > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From tartley at tartley.com Mon Oct 19 16:18:46 2009 From: tartley at tartley.com (Jonathan Hartley) Date: Mon, 19 Oct 2009 15:18:46 +0100 Subject: [IronPython] Type analysis of expression In-Reply-To: <1256167.1255961375078.JavaMail.root@n17> References: <4ADC0F5A.8010809@gmx.de> <4ADC4B84.6090505@voidspace.org.uk> <1256167.1255961375078.JavaMail.root@n17> Message-ID: <4ADC7546.4080809@tartley.com> 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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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 >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > -- Jonathan Hartley Made of meat. http://tartley.com tartley at tartley.com +44 7737 062 225 twitter/skype: tartley From jdhardy at gmail.com Mon Oct 19 16:26:45 2009 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 19 Oct 2009 08:26:45 -0600 Subject: [IronPython] Wildcard conf on IIS6 In-Reply-To: <20091019100924.GQ22055@nysv.org> References: <20091009192947.GJ17007@nysv.org> <20091018105234.GB22055@nysv.org> <20091019071927.GO22055@nysv.org> <8cd017b80910190109j5da7ef4rf65934bd5db38be@mail.gmail.com> <20091019100924.GQ22055@nysv.org> Message-ID: 2009/10/19 Markus T?rnqvist : > On Mon, Oct 19, 2009 at 10:09:14AM +0200, Dody Gunawinata wrote: >> MetaBase.xml and MBSchema.xml. IIS stores these files in the >>*systemroot*\System32\Inetsrv >>folder of your computer > > Cool! > > Is there anything specific I should be on the lookout for? Nope. I just want to check your configuration against mine (I have a feeling we're missing something simple), and this is the easiest way. - Jeff From mjt at nysv.org Mon Oct 19 16:28:00 2009 From: mjt at nysv.org (Markus =?iso-8859-1?Q?T=F6rnqvist?=) Date: Mon, 19 Oct 2009 17:28:00 +0300 Subject: [IronPython] Wildcard conf on IIS6 In-Reply-To: References: <20091009192947.GJ17007@nysv.org> <20091018105234.GB22055@nysv.org> <20091019071927.GO22055@nysv.org> <8cd017b80910190109j5da7ef4rf65934bd5db38be@mail.gmail.com> <20091019100924.GQ22055@nysv.org> Message-ID: <20091019142800.GU22055@nysv.org> On Mon, Oct 19, 2009 at 08:26:45AM -0600, Jeff Hardy wrote: > >Nope. I just want to check your configuration against mine (I have a >feeling we're missing something simple), and this is the easiest way. I emailed you the files... I'll be afk for a couple of hours, but otherwise I could try to keep an eye on my mail if you'd find anything :) ... Still can't understand why wildcard isn't "every imaginable path" :| -- mjt From vernondcole at gmail.com Mon Oct 19 16:28:51 2009 From: vernondcole at gmail.com (Vernon Cole) Date: Mon, 19 Oct 2009 08:28:51 -0600 Subject: [IronPython] Type analysis of expression In-Reply-To: <4ADC4B84.6090505@voidspace.org.uk> References: <4ADC0F5A.8010809@gmx.de> <4ADC4B84.6090505@voidspace.org.uk> Message-ID: Christian: While Python is type agnostic, most databases are pretty fussy about what you feed them. I presume that you need to convert the user's data into a form acceptable to the database. You do not specify what tool you are using to write your results to the database, so I will provide several answers to your question... 1) If you are writing to the database using Python, and you are using a fully PEP 249 compliant database module: The database module should attempt the conversion for you, giving an exception if it cannot. You will need to do the most obvious conversions yourself such as making a number into a string, so an "if" "except" construct should do handily. As far as I know, only the adodbapi module is both fully PEP 249 compliant and implemented in IronPython. http://sourceforge.net/projects/adodbapi 2) You can use Python's "isinstance" built in function to see what the user sent you:


impert types
a = theOutputFromYourUser()
if isinstance(a,types.StringType):
  print "it was a string"
if isinstance(a, (types.FloatType, types.IntType)):
  print "it was a number"

3) You can take advantage of python's "duck type" capability by simply trying the user's output to see if it will work as a given type...


numericResult = None
stringResult = None
a = theOutputFromYourUser()
try:
    numericResult = float(a)
except:
   try:
        stringResult = str(a)
    except:
        pass
if numericResult != None:
   # your numeric stuff here
elif stringResult != None:
   # your string stuff here
else:
   # your error handling here.

4) Use some combination of the above. For example: adodbapi uses a dictionary dispatch table to chose which conversion to call, which is a variation on option 2, but then uses exception handling to catch errors within the specific code for some conversions. YMMV -- Vernon Cole On Mon, Oct 19, 2009 at 5:20 AM, Michael Foord wrote: > 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 >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.p.lepisto at intel.com Mon Oct 19 16:29:48 2009 From: stephen.p.lepisto at intel.com (Lepisto, Stephen P) Date: Mon, 19 Oct 2009 07:29:48 -0700 Subject: [IronPython] Type analysis of expression In-Reply-To: <4ADC7546.4080809@tartley.com> References: <4ADC0F5A.8010809@gmx.de> <4ADC4B84.6090505@voidspace.org.uk> <1256167.1255961375078.JavaMail.root@n17> <4ADC7546.4080809@tartley.com> Message-ID: <6AF28EB9F93A354894F2F3916DF6F96E0C82C4DAEC@orsmsx510.amr.corp.intel.com> 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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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 >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > -- Jonathan Hartley Made of meat. http://tartley.com tartley at tartley.com +44 7737 062 225 twitter/skype: tartley _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From vernondcole at gmail.com Mon Oct 19 16:38:03 2009 From: vernondcole at gmail.com (Vernon Cole) Date: Mon, 19 Oct 2009 08:38:03 -0600 Subject: [IronPython] Type analysis of expression In-Reply-To: <6AF28EB9F93A354894F2F3916DF6F96E0C82C4DAEC@orsmsx510.amr.corp.intel.com> References: <4ADC0F5A.8010809@gmx.de> <4ADC4B84.6090505@voidspace.org.uk> <1256167.1255961375078.JavaMail.root@n17> <4ADC7546.4080809@tartley.com> <6AF28EB9F93A354894F2F3916DF6F96E0C82C4DAEC@orsmsx510.amr.corp.intel.com> Message-ID: 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 < stephen.p.lepisto at intel.com> 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: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] 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: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] 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 > >> Users at lists.ironpython.com > >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >> > > > > > > > > -- > Jonathan Hartley Made of meat. http://tartley.com > tartley at tartley.com +44 7737 062 225 twitter/skype: tartley > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tartley at tartley.com Mon Oct 19 17:44:48 2009 From: tartley at tartley.com (Jonathan Hartley) Date: Mon, 19 Oct 2009 16:44:48 +0100 Subject: [IronPython] Type analysis of expression In-Reply-To: <25232872.1255963395484.JavaMail.root@n17> References: <4ADC0F5A.8010809@gmx.de> <4ADC4B84.6090505@voidspace.org.uk> <1256167.1255961375078.JavaMail.root@n17> <4ADC7546.4080809@tartley.com> <6AF28EB9F93A354894F2F3916DF6F96E0C82C4DAEC@orsmsx510.amr.corp.intel.com> <25232872.1255963395484.JavaMail.root@n17> Message-ID: <4ADC8970.3070307@tartley.com> 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 > > 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: users-bounces at lists.ironpython.com > > [mailto:users-bounces at lists.ironpython.com > ] 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: users-bounces at lists.ironpython.com > > [mailto:users-bounces at lists.ironpython.com > ] 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 > >> Users at lists.ironpython.com > >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > >> > > > > > > > > -- > Jonathan Hartley Made of meat. http://tartley.com > tartley at tartley.com +44 7737 062 > 225 twitter/skype: tartley > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Jonathan Hartley Made of meat. http://tartley.com tartley at tartley.com +44 7737 062 225 twitter/skype: tartley From merllab at microsoft.com Mon Oct 19 17:53:05 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Mon, 19 Oct 2009 08:53:05 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <1b92ee3a-d678-49bf-8551-85db4c0d0922@tk5-exsmh-c101.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/60269. ADDED SOURCES $/IronPython/IronPython_Main/Src/Tests/XLang $/IronPython/IronPython_Main/Src/Tests/XLang/some_ruby_file.rb MODIFIED SOURCES $/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/TypeInfo.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/CommonDictionaryStorage.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Importer.cs $/IronPython/IronPython_Main/Src/IronPython/Runtime/Set.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Actions/Calls/OverloadResolver.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ComRuntimeHelpers.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LightCompiler.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instruction.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/ErrorSink.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Hosting/ScriptScope.cs $/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Hosting/ErrorListenerProxy.cs $/IronPython/IronPython_Main/Src/IronPythonConsole/Console.cs $/IronPython/IronPython_Main/Src/Tests/interop/net/method/test_arguments.py $/IronPython/IronPython_Main/Src/Tests/test_set.py $/IronPython/IronPython_Main/Src/Tests/test_importpkg.py $/IronPython/IronPython_Main/Src/Tests/test_cliclass.py $/IronPython/IronPython_Main/Src/Tests/XLang/some_ruby_file.rb CHECKIN COMMENTS -------------------------------------------------------------------------------- Changeset Id: 1220861 Date: 10/17/2009 3:41:20 PM (dinov) Fixes an issue reported by Resolver relating to sets & bad hash implementations. Our Contains check can fail to find the original object if the hash code changes. Instead we now track a version number on dictionary objects. Resolver has already worked around this but this makes us more compatible w/ Cpython. Test added to test_set Fixes another Resolver bug (http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=24929) - __float__ isn?t defined on Int64. We need to consider ConvertTo* methods and manifest them as __float__ methods. Test added to test_cliclass. Fixes a broken perf test ? we need to load IronPython from configuration not just using the Python class so that other languages will be available via clr.Use. Test added to test_cliclass. Fixes an importer issue which prevents json from being imported. We are doing too many checks if __package__ is set which causes the import to fail. Test added to test_importpkg. Also fixing an issue failing in the full sign off run ? ComRuntimeHelpers is generating unsafe methods into Snippets which fail verification. Now we just create a one-off assembly for this and never verify it (test already exists in full sign off run). (Shelveset: More26BugFixesAndRaiseModesTimeout;REDMOND\dinov | SNAP CheckinId: 9643) From merllab at microsoft.com Mon Oct 19 21:08:37 2009 From: merllab at microsoft.com (merllab at microsoft.com) Date: Mon, 19 Oct 2009 12:08:37 -0700 Subject: [IronPython] IronPython 2.6 CodePlex Source Update Message-ID: <19540d52-ef12-41d1-80fa-b1bed375adcc@tk5-exsmh-c102.redmond.corp.microsoft.com> This is an automated email letting you know that sources have recently been pushed out. You can download these newer sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/60285. ADDED SOURCES $/IronPython/IronPython_2_6/Src/Tests/XLang $/IronPython/IronPython_2_6/Src/Tests/XLang/some_ruby_file.rb MODIFIED SOURCES $/IronPython/IronPython_2_6/Doc/dotnet-integration.rst $/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/ComInterop/ComRuntimeHelpers.cs $/IronPython/IronPython_2_6/Src/IronPython/Runtime/Binding/PythonGetMemberBinder.cs $/IronPython/IronPython_2_6/Src/IronPython/Runtime/Binding/PythonProtocol.Operations.cs $/IronPython/IronPython_2_6/Src/IronPython/Runtime/Types/OldInstance.cs $/IronPython/IronPython_2_6/Src/IronPython/Runtime/Types/PythonTypeDataSlot.cs $/IronPython/IronPython_2_6/Src/IronPython/Runtime/Types/ReflectedExtensionProperty.cs $/IronPython/IronPython_2_6/Src/IronPython/Runtime/CommonDictionaryStorage.cs $/IronPython/IronPython_2_6/Src/IronPythonConsole/Console.cs $/IronPython/IronPython_2_6/Src/IronPython/Runtime/Operations/PythonOps.cs $/IronPython/IronPython_2_6/Src/IronPython/Runtime/Operations/CustomTypeDescHelpers.cs $/IronPython/IronPython_2_6/Src/IronPython/Runtime/Importer.cs $/IronPython/IronPython_2_6/Doc/IronPython.css $/IronPython/IronPython_2_6/Src/IronPython/Runtime/Binding/MetaPythonType.Members.cs $/IronPython/IronPython_2_6/Src/IronPython/Runtime/Types/NewTypeMaker.cs $/IronPython/IronPython_2_6/Src/IronPython/Runtime/Types/TypeInfo.cs $/IronPython/IronPython_2_6/Src/IronPython/Runtime/Set.cs $/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/Math/BigIntegerV4.cs $/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/Utils/ReflectionUtils.cs $/IronPython/IronPython_2_6/Src/Tests/interop/net/type/test_defaultmember.py $/IronPython/IronPython_2_6/Src/Tests/Modes/ConsoleFlags.ps1 $/IronPython/IronPython_2_6/Src/Tests/check_result.bat $/IronPython/IronPython_2_6/Src/Tests/run_transformed.bat $/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Scripting.Core/Actions/DynamicMetaObjectBinder.cs $/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Scripting.Debugging/DebuggableLambdaBuilder.cs $/IronPython/IronPython_2_6/Src/Tests/test_importpkg.py $/IronPython/IronPython_2_6/Src/Tests/test_cliclass.py $/IronPython/IronPython_2_6/Src/Tests/test_set.py $/IronPython/IronPython_2_6/Src/Tests/XLang/some_ruby_file.rb $/IronPython/IronPython_2_6/Tutorial/Tutorial.htm From christian2.schmidt at gmx.de Mon Oct 19 21:12:26 2009 From: christian2.schmidt at gmx.de (Christian Schmidt) Date: Mon, 19 Oct 2009 21:12:26 +0200 Subject: [IronPython] Type analysis of expression In-Reply-To: <4ADC8970.3070307@tartley.com> References: <4ADC0F5A.8010809@gmx.de> <4ADC4B84.6090505@voidspace.org.uk> <1256167.1255961375078.JavaMail.root@n17> <4ADC7546.4080809@tartley.com> <6AF28EB9F93A354894F2F3916DF6F96E0C82C4DAEC@orsmsx510.amr.corp.intel.com> <25232872.1255963395484.JavaMail.root@n17> <4ADC8970.3070307@tartley.com> Message-ID: <4ADCBA1A.9070206@gmx.de> Hi all, thanks for your discussion. Actually I'm having an in-memory table of strongly typed columns. The user can provide per-row (python-)expressions as additional columns. Now if the user wants his result to be exported to a database (e.g. SQL Server or Oracle) I need to set a type for each column - also for the expression columns. I thought there might be a way to figure out the return type in a similar way for example Boo (boo.codehaus.org) does at compile time. When an expression is parsed at runtime, the interpreter also needs to decide which .NET-functions to call. For strongly typed input these functions should normally have typed return values... Wouldn't this work somehow? If the Boo way is not possible then the only option is evaluating the expressions for some random rows and coerce to a common type. What would be the rules? int->float->string is trivial, but what about decimal, int64, double, ...? I assume python must have implemented these rules somewhere. How would one have to implement the general function: Type GetCoercedType(IEnumerable