[IronPython] Issue Triage

[Steve Dower]

Going by the Windows documentation, I would expect REG_EXPAND_SZ to
_optionally_ expand when retrieving the value, but never expand when
setting it.

The main set of Windows functions don't expand the value - the type is
only an indicator that it may contain environment variables. That
said, the only reason you wouldn't expand it is if you need the value
to be portable to another user/system (%APPDATA% comes to mind here),
so it makes sense for things to be simplified here by default (IIRC
there is one Win32 function that will expand it, probably exposed by
the shell rather than the kernel).

Of course, without an option to switch behaviour, you are guaranteed
to upset somebody. </IMHO>

On Mon, Jan 17, 2011 at 05:33, Richard Nienaber <rjnienaber at gmail.com> wrote:
>> Hmmm... it is still probably worth filing an issue with CPython:
>>
>> http://bugs.python.org/
>
> Will do.
> On Sun, Jan 16, 2011 at 5:29 PM, Michael Foord <fuzzyman at 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
>> keyword argument is also treated as args for params array
>> unable to invoke delegate object with method which takes ref args
>> binder does not handle argument list with keyword and tuple correctly for
>> .net methods
>> tracking: wrong message when calling System.Activator.CreateInstance(None)
>> clr.AddReference need invalidate the cached rules related to
>> NamespaceTracker
>> Questions:
>>
>> Incompatibility between CPy and IPy in the way REG_EXPAND_SZ works in
>> _winreg module.
>>
>> 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 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
>>
>> 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). 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 list
>> Users at lists.ironpython.com
>> http://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 at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>