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 » dc_view

Log in
Name

Password

 
 


Dublin Core Elements

The Dublin Core metadata element set is a standard for cross-domain information resource description.
Element Description Value
Identifier resource ID http://old.zope.org/Members/Brian/PythonNet/Collector/14
Title resource name Suggestion for change in handling of out parameters
Description resource summary 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.
Creator resource creator glchapman
Date default date 2005-06-08 14:35:43
Format resource format text/html
Type resource type Collector Issue
Subject resource keywords General, feature, medium
Contributors resource collaborators
Language resource language
Publisher resource publisher No publisher
Rights resource copyright


Additional Zope Elements

Element Description Value
CreationDate date resource created 2005-06-08 14:08:15
ModificationDate date resource last modified 2005-06-08 14:35:43
EffectiveDate date resource becomes effective None
ExpirationDate date resource expires None

Backlinks: via Google / Technorati