> > Hmmm... it is still probably worth filing an issue with CPython:
> <http://bugs.python.org/>http://bugs.python.org/ Will do. On Sun, Jan 16, 2011 at 5:29 PM, Michael Foord <fuzzy...@voidspace.org.uk>wrote: > On 16/01/2011 09:23, Richard Nienaber wrote: > > I've closed the following issues: > > test blocking: support setting field of value type when calling > ctor<http://ironpython.codeplex.com/workitem/24008> > keyword argument is also treated as args for params > array<http://ironpython.codeplex.com/workitem/24000> > unable to invoke delegate object with method which takes ref > args<http://ironpython.codeplex.com/workitem/24009> > binder does not handle argument list with keyword and tuple correctly for > .net methods <http://ironpython.codeplex.com/workitem/24001> > tracking: wrong message when calling > System.Activator.CreateInstance(None)<http://ironpython.codeplex.com/workitem/24007> > clr.AddReference need invalidate the cached rules related to > NamespaceTracker <http://ironpython.codeplex.com/workitem/24012> > > Questions: > > - Incompatibility between CPy and IPy in the way REG_EXPAND_SZ works in > _winreg module. <http://ironpython.codeplex.com/workitem/24042> > > It seems to me that in this case that IronPython was doing the right > thing, and CPython was doing the wrong thing. > REG_EXPAND_SZ<http://msdn.microsoft.com/en-us/library/ms724884%28v=vs.85%29.aspx> > seems > to mean that environment variables should be expanded when the value is > inserted into the registry. I've assumed here that even if CPython does the > wrong thing, IronPython should follow the behaviour of CPython (and closed > the issue). > > Hmmm... it is still probably worth filing an issue with CPython: > > http://bugs.python.org/ > > All the best, > > Michael > > > - Code has recently been added to fix this issue: types in assemblies > loaded with .AddReferenceToFileAndPath() are not importable if they > reference other assemblies<http://ironpython.codeplex.com/workitem/25124> > > Should I close this one as well or does this need to make it into a > build first? > > > - -X:PreferComDispatch > > I have come across quite a few issues where there are inconsistencies > when IronPython is started with/without the '-X:PreferComDispatch' switch > (like > this one <http://ironpython.codeplex.com/workitem/24013>). If I look at > the IronPython console help this switch is absent and attempting to run it > gives me the error 'File -X:PreferComDispatch does not exist.'. Is this > option no longer available/supported? If not, what should be done with these > issues? > > Richard > > > > > _______________________________________________ > Users mailing > listUsers@lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > -- http://www.voidspace.org.uk/ > > May you do good and not evil > May you find forgiveness for yourself and forgive others > May you share freely, never taking more than you give. > -- the sqlite blessing http://www.sqlite.org/different.html > >
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
