[IronPython] Weird Anomoly with SetStandardOutput

Michael Foord fuzzyman at voidspace.org.uk
Tue Apr 3 00:36:28 CEST 2007


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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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
>> 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
>
>   




More information about the Ironpython-users mailing list