The reason why I asked about multiple engine support is that it's actually a feature we don't know if we can maintain long-term. The problem is that it's actually impossible for us to always know what engine we were calling from. For example if we need to call back into something that requires an engine from a .NET ToString method we cannot properly flow the context into ToString and therefore we lose what engine was calling.
So this might be a feature which disappears in later versions of IronPython. Instead we'd encourage hosting each engine in its own app domain leveraging the CLR's own isolation mechanisms. I don't believe that decision is entirely set in stone so it'd be interesting to hear what everyone thinks about it. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, April 02, 2007 3:36 PM To: Discussion of IronPython Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput Dino Viehland wrote: > This seems to work for me: > > from IronPython.Hosting import PythonEngine > from System.IO import Stream > > class C(Stream): > @property > def CanRead(self): return False > @property > def CanSeek(self): return False > @property > def CanWrite(self): return True > @property > def Position(self): return 0 > def Write(self, chars, offset, count): > from System import Console > Console.WriteLine(chars) > def Flush(self): pass > > Ha - they're properties. I was implementing them as methods - and it *appeared* to work... Cool - thanks. We're only just starting to use the multiple engine support. Thanks Dino. Michael > py.SetStandardOutput(C()) > py.Execute('print 3') > > > I stuck to Console.WriteLine just to avoid having to think about sys across > engines. > > Just out of curiosity - do you use the multiple engine support extensively? > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord > Sent: Monday, April 02, 2007 3:09 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Weird Anomoly with SetStandardOutput > > Michael Foord wrote: > >> Michael Foord wrote: >> >> >>> Hello all, >>> >>> If I create a subclass of 'Stream' from IronPython - and set it onto a >>> PythonEngine using 'SetStandardOutput', then it fails with the following >>> message: >>> >>> Traceback (most recent call last): >>> File C:\Python Projects\modules in >>> progress\ironpython\embeddingDivert.py, lin >>> e 32, in Initialize >>> File , line 0, in SetStandardOutput##94 >>> TypeError: issubclass: arg 1 must be a class >>> >>> If I define an empty class, and set this then I get the expected error >>> 'AttributeError: 'Diverter' object has no attribute 'get_CanSeek'. >>> >>> [snip...] >>> >>> Unfortunately this problem is going to block us very rapidly at >>> resolver. We can probably get round it by creating the stream subclass >>> in C# - but what is the problem with doing it from IronPython ? >>> >>> >>> >>> >> Except that I realise that you may not have anticipated your users >> passing .NET subclasses from one IronPython engine to another... >> >> Can this be fixed ? >> >> > Oh, and : > > http://www.voidspace.org.uk/ironpython/ip_in_ip.shtml > > Embedding IronPython in IronPython. > > Michael Foord > > >> Michael >> >> _______________________________________________ >> users mailing list >> [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 > _______________________________________________ > users mailing list > [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 _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
