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 1.1

[IronPython] 1.1 schedule?

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

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, Do

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 (http://msdn2.microsoft.com/en-us/library/system.io.compression.gzipstream.gzipstrea

Re: [IronPython] Setting func_name

I've opened CodePlex bug #6142 for this (http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=6142). Thanks for finding & reporting this! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo Sent: Friday, December 01, 20

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 (http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&Wor

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 > > OK. Thanks for the heads up. Mind you I find t

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 ___ users mailing list users@lists.ironpyth

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

[IronPython] Setting func_name

This is broken. >>> def f(): pass ... >>> f.func_name = 'g' >>> print f >>> f.__name__ 'f' -- Seo Sanghyeon ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Groping in the dark

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, DockStyle, Form, Keys, MenuStrip, ToolStripMenuItem, Too

[IronPython] unicode object type

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

[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.