[IronPython] SymbolTable.Empty

Warning: obscure. from IronPython.Runtime import SymbolTable print str(SymbolTable.Empty) str() should not return any non-strings. Actually, IronPython seems to enforce this for user types, just like CPython. But it doesn't enforce this for reflected types, where .NET ToString() can return null.

[IronPython] unicode object type

CPython str(None) 'None' unicode(None) u'None' type(unicode(None)) type 'unicode' type(unicode('ble')) type 'unicode' IronPython str(None) 'None' unicode(None) 'None' type(unicode(None)) type 'str' type(unicode('ble')) type 'str' Is this the correct behavior? - Sylvain

Re: [IronPython] Setting func_name

A patch is available. http://fepy.sourceforge.net/patches.html patch-ironpython-set-func-name -- Seo Sanghyeon ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] unicode object type

Sylvain Hellegouarch wrote: Is this the correct behavior? yes. a Python implementation is not required to have a distinct Unicode string type; see: http://jython.sourceforge.net/docs/differences.html /F ___ users mailing list

Re: [IronPython] unicode object type

Fredrik Lundh wrote: Sylvain Hellegouarch wrote: Is this the correct behavior? yes. a Python implementation is not required to have a distinct Unicode string type; see: http://jython.sourceforge.net/docs/differences.html /F OK. Thanks for the heads up. Mind you I find that a

Re: [IronPython] SymbolTable.Empty

Thanks for reporting this. I'm not too concerned about someone doing this on SymbolTable, but for reflected types in general I think it makes sense that we should transform null into a string. I've opened CodePlex bug #6141

Re: [IronPython] engine.Dispose closes the stdout stream

I've looked into this on our side the guidance seems to be that we should add an overload of Set* that allows you to specify if we should close the stream or not. This is analogous to the GZipStream constructor

Re: [IronPython] Groping in the dark

On 12/1/06, William Reade [EMAIL PROTECTED] wrote: Hi Patrick I haven't been able to see the anomalies you mention -- perhaps the following sample will help. --- import clr clr.AddReference(System.Windows.Forms) from System.Windows.Forms import ( Application,

[IronPython] 1.1 schedule?

http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=IronPythonReleaseId=161 says 2006-12-01 for the release date, which have already passed. Any ETA? -- Seo Sanghyeon ___ users mailing list users@lists.ironpython.com

Re: [IronPython] 1.1 schedule?

I believe our current thinking is that 1.1 Alpha will actually be sometime next week. That will include most of new functionality that we have written for 1.1 along with some bug fixing work that we've done (these changes are all currently on CodePlex today in source form). Then we'll ship