You are not logged in Log in Join
You are here: Home » Members » Brian » Python For .NET » Python for .NET Issue Tracker » Suggestion for change in handling of out parameters » collector_issue_contents

Log in
Name

Password

 
 
Issue 14 of Python for .NET Issue Tracker [PythonNet]
Title: Suggestion for change in handling of out parameters
Status: Pending Security related: No
Description: Currently, PythonNet differs from IronPython (and pythoncom) in requiring a python parameter to be passed in the position of an out parameter. That i...
From: glchapman on: Jun 8, 05 14:08
glchapman Last update: Jun 8, 05 14:35
Topic/class: General/feature Importance: medium
Version info: 1.0 rc2
Issue 14 Transcript
2 entries
= Comment - Entry #2 by Brian on Jun 8, 2005 2:35 pm

Thanks for the comprehensive writeup. I'm
generally in favor of trying to do things the
same way as IP is (or will) do them if possible. Is the handling of out/ref etc. pretty much settled now in IP? I haven't been able to pay as much attention as I probably should to that list ;( If it seems settled and non-controversial, I'm happy to make the changes.

If you can send your patch (you can email it to me: [email protected]), that would be great!

-BL
________________________________________
= Request - Entry #1 by glchapman on Jun 8, 2005 2:08 pm

Currently, PythonNet differs from IronPython (and pythoncom) in requiring a python parameter to be passed in the position of an out parameter. That is, PythonNet requires:

  Double.TryParse("1.23", 0)  // .NET v2 overload of TryParse

where IronPython would have:

  Double.TryParse("1.23")

I think PythonNet should adopt the convention of not including a parameter in the python call signature if that parameter is marked out-only.

By out-only, I mean (IsOut && !IsIn) when testing the ParameterInfo. There are some parameters which are both in and out, notably the buffer parameter of Stream.Read. In this case, of course, python code must supply a parameter (interestingly, I believe IronPython 0.7.5 may have a bug in ReflectedMethodBase.BindArgs in that it appears to ignore all IsOut params without checking IsIn).

The buffer param of Stream.Read brings up another difference with IronPython: it is not marked as an IsByRef type, and so IronPython will not include it in its result tuple (see ReflectedMethodBase.MakeReturnValue), whereas PythonNet will (since it is marked IsOut). I prefer IronPython's behavior here.

So, I hope you will consider adopting the following rules for method calls:

  1) Parameters for which (IsOut && !IsIn) is true do not appear in the python call signature.
  2) The python result of a method call is, in the general case, a tuple made up of the method result (if any) followed by all the IsByRef parameters.
  3) If the above tuple would have only one element, then that element is returned directly.
  4) If the tuple has no elements, then None is returned.

I patched methodbinder.cs in RC1 to incorporate these rules; I can send you a diff if you're interested.