RE: [IronPython] Questions for FAQ or User Guide
That is a good suggestion. The initial look shows that it would be quite possible to implement it. I'll give it a try. Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Monson-Haefel Sent: Tuesday, April 19, 2005 6:29 PM To: Discussion of IronPython Subject: Re: [IronPython] Questions for FAQ or User Guide It might be better if IronPython auto converted the list of real number to an array in this case. If, that is, all the types in the list can be widened to the correct type, or if the parameter is an array of objects. That way you don't have to call an explicit method to set the list to an array of Double types. The reason, I think this is important, is that in Python developers will avoid explicit typed of arrays in favor of loose typed lists because its more Pythonic. Since interaction with general purpose languages (strongly typed) will require more strict typing, the interpreter or compiler should make that transformation (from List to array of doubles) implicitly, or if it can't be done throw an exception. Otherwise, you are forcing IronPython developers to adhere to strict typing whenever they script interactions of objects defined by general purpose languages like C#. richard ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Questions for FAQ or User Guide
It's certainly possible, PyObjC does a lot of conversions like this and it works rather well. -bob On Apr 20, 2005, at 2:17 PM, Martin Maly wrote: That is a good suggestion. The initial look shows that it would be quite possible to implement it. I'll give it a try. Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Monson-Haefel Sent: Tuesday, April 19, 2005 6:29 PM To: Discussion of IronPython Subject: Re: [IronPython] Questions for FAQ or User Guide It might be better if IronPython auto converted the list of real number to an array in this case. If, that is, all the types in the list can be widened to the correct type, or if the parameter is an array of objects. That way you don't have to call an explicit method to set the list to an array of Double types. The reason, I think this is important, is that in Python developers will avoid explicit typed of arrays in favor of loose typed lists because its more Pythonic. Since interaction with general purpose languages (strongly typed) will require more strict typing, the interpreter or compiler should make that transformation (from List to array of doubles) implicitly, or if it can't be done throw an exception. Otherwise, you are forcing IronPython developers to adhere to strict typing whenever they script interactions of objects defined by general purpose languages like C#. richard ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Questions for FAQ or User Guide
Cool! On Apr 20, 2005, at 1:17 PM, Martin Maly wrote: That is a good suggestion. The initial look shows that it would be quite possible to implement it. I'll give it a try. Martin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Monson-Haefel Sent: Tuesday, April 19, 2005 6:29 PM To: Discussion of IronPython Subject: Re: [IronPython] Questions for FAQ or User Guide It might be better if IronPython auto converted the list of real number to an array in this case. If, that is, all the types in the list can be widened to the correct type, or if the parameter is an array of objects. That way you don't have to call an explicit method to set the list to an array of Double types. The reason, I think this is important, is that in Python developers will avoid explicit typed of arrays in favor of loose typed lists because its more Pythonic. Since interaction with general purpose languages (strongly typed) will require more strict typing, the interpreter or compiler should make that transformation (from List to array of doubles) implicitly, or if it can't be done throw an exception. Otherwise, you are forcing IronPython developers to adhere to strict typing whenever they script interactions of objects defined by general purpose languages like C#. richard ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
RE: [IronPython] Questions for FAQ or User Guide
But where should the line be drawn in favor of not throwing casting errors? I wouldn't want to use something that didn't know how to play nice when it leaves its own little world. From: [EMAIL PROTECTED] on behalf of Martin Maly Sent: Wed 4/20/2005 11:17 AM To: Discussion of IronPython Subject: RE: [IronPython] Questions for FAQ or User Guide That is a good suggestion. The initial look shows that it would be quite possible to implement it. I'll give it a try. <>___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Questions for FAQ or User Guide
Well, the way I see it (not that my opinion is all that important, but ...) you should be able to use more explicit typing by declaring the System.Double [] type if you desire, but IronPython should attempt to do the transformation if you choose not to (or neglect) to do so. That way you get both options. Very explicit type conversions or implicit conversions. It becomes a matter of style. The thing to remember, IMO, is that IronPython is a dynamic language and by nature dynamic language are loosely typed. If you require explicit typing, than you are breaking that model, in which case you might as well not use IronPython at all. On Apr 20, 2005, at 3:49 PM, Keith J. Farmer wrote: But where should the line be drawn in favor of not throwing casting errors? I wouldn't want to use something that didn't know how to play nice when it leaves its own little world. From: [EMAIL PROTECTED] on behalf of Martin Maly Sent: Wed 4/20/2005 11:17 AM To: Discussion of IronPython Subject: RE: [IronPython] Questions for FAQ or User Guide That is a good suggestion. The initial look shows that it would be quite possible to implement it. I'll give it a try. ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
RE: [IronPython] Questions for FAQ or User Guide
Well, the point I was going to bring up last night was that one could live very happily within IronPython, following Pythonic customs; but one should be expected to follow the customs that exist in the CLR world when talking with it. Some types I can see free conversions for -- particularly value types. Some types, such as arrays, would be tricker and I suspect impossible in cases: for those I'd desire strong-typing. For stuff that IronPython may expose to the outside world, strong-typing should be a requirement (even if it's declaring the type to be Object), no? C#2 brings on type inference for delegates, so I can see a similar scheme going on. For IronPython I think it'd be closer to a dispatch based on type, which I can see getting very bloaty. I'm not familiar with how Jim addressed this in Jython? From: [EMAIL PROTECTED] on behalf of Richard Monson-Haefel Sent: Wed 4/20/2005 2:22 PM To: Discussion of IronPython Subject: Re: [IronPython] Questions for FAQ or User Guide Well, the way I see it (not that my opinion is all that important, but ...) you should be able to use more explicit typing by declaring the System.Double [] type if you desire, but IronPython should attempt to do the transformation if you choose not to (or neglect) to do so. That way you get both options. Very explicit type conversions or implicit conversions. It becomes a matter of style. The thing to remember, IMO, is that IronPython is a dynamic language and by nature dynamic language are loosely typed. If you require explicit typing, than you are breaking that model, in which case you might as well not use IronPython at all. <>___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
RE: [IronPython] Questions for FAQ or User Guide
I just came across Starkiller: http://www.python.org/pycon/dc2004/papers/1/paper.pdf <>___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Questions for FAQ or User Guide
On 4/20/05, Keith J. Farmer <[EMAIL PROTECTED]> wrote: > I just came across Starkiller: > http://www.python.org/pycon/dc2004/papers/1/paper.pdf Unfortunately Starkiller will most likely not be released. Michael Salib was under the employ of MIT when he wrote it and therefor does not own the code. When I talked to him at PyCon he said he had started on a rewrite to get around these issues and that releasing it would be possible but would take convincing MIT the ideas have no commercial viability (standard operating procedure there, but would take months minimum and quite a bit of effort). Also, Starkiller makes assumptions that IronPython absolutely cannot (no eval and others more egregious). And now, on the extremely blindingly bright side of things, there is PyPy. It does type inferencing in a rather different way than Starkiller, and is designed for targeting different output formats (CLI!) So the idea is definitely alive and kicking (and now well funded by the European Union). As for why I'm so negative about Starkiller's application; blame Brett Cannon. He gave a good presentation on why type inferencing is very hard and doesn't gain much in Python without making changes to the language itself. ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
RE: [IronPython] Questions for FAQ or User Guide
Nonetheless, it does present some basis from which to start. I also suspect, specifically regarding the Starkiller paper, that some of the problems aren't all that relevent. For example, dynamic method creation: is that something that is going to be exposed outside of IronPython? If not, then do we need to worry about it? If so, such as a callback defined through some hosted scripting environment, then perhaps we say that callbacks must be unambiguous about their type. I'm willing to suggest that all such reference types must be strongly typed. Strings, numbers, and other primitives should be fairly simple otherwise. Not that my musings should matter -- this is well out of my experience. ;) -Original Message- From: Timothy Fitz [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 20, 2005 9:22 PM Also, Starkiller makes assumptions that IronPython absolutely cannot (no eval and others more egregious). And now, on the extremely blindingly bright side of things, there is PyPy. It does type inferencing in a rather different way than Starkiller, and is designed for targeting different output formats (CLI!) So the idea is definitely alive and kicking (and now well funded by the European Union). ___ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
