[swift-evolution] Python Interop with Swift 4+

Chris Lattner sabre at nondot.org
Mon Nov 20 12:39:29 CST 2017


> On Nov 20, 2017, at 12:16 AM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> I’ve had a quick look into how your proposals will allow interop with other dynamic languages. It seems that the model that you chose, where calling a function is a two-step process (getting a DynamicCallable function from a DynamicMemberLookupProtocol type) fits Python like a glove, where everything (including functions) is a PyVal. But in other languages, like Ruby, this model makes less sense.

Right, this was also brought up in the DynamicCallable thread, the example given before was Squeak, another Smalltalky language.

It turns out that the right ultimate design for DynamicCallable is probably to have two different entry points: one for direct-function-like calls and one for methods-with-keywords calls, e.g.:

	fn(arg: 1, arg2: 2)   // function like
	obj.method(arg: 1, arg2: 2)   // method like

It is straight-forward (and fits very very naturally into the Swift call model) to support the second one as an atomic thing, which is I think what you’re getting at.  I plan to revise the DynamicCallable proposal to incorporate this directly into the model, but haven’t had time to do so yet.

-Chris




> For example, here is how one uses the Ruby C API to call a method of an object:
> 
> result = rb_funcallv(obj, rb_intern(“methodName"), arg_count, args);
> 
> And here is how one gets and sets instance variables:
> 
> x = rb_iv_get(obj, "@x");
> rb_iv_set(obj, "@x", x);
> 
> Moreover, Ruby allows classes to have instance variables with the same name as methods:
> 
> class Foo
>   def initialize()
>     @bar = 5
>   end
> 
>   def bar()
>     puts “Hello"
>   end
> end
> 
> In that case, how would one implement DynamicMemberLookupProtocol for the lookup of bar, and what would the return value be? Its entirely context sensitive.
> 
> If we want a model that fits the most languages, shouldn’t we redefine DynamicCallable to specify the function name?
> 
> protocol DynamicCallable {
>     associatedtype DynamicCallableArgument
>     associatedtype DynamicCallableResult
> 
>     func dynamicCall(function: String, arguments: [(String, DynamicCallableArgument)]) throws -> DynamicCallableResult
> }
> 
> This would work in both languages:
> 
> extension PyVal: DynamicMemberLookupProtocol, DynamicCallable {
>     func dynamicCall(function: String, arguments: [(String, PyVal)]) throws -> PyVal {
>         let functionVal = self[function]
>         functionVal.call(arguments)
>     }
> }
> 
> extension RbVal: DynamicMemberLookupProtocol, DynamicCallable {
>     func dynamicCall(function: String, arguments: [(String, PyVal)]) throws -> PyVal {
>         return rb_funcallv(self, rb_intern(function), arguments.count, arguments);
>     }
> }
> 
> Thoughts?
> David.
> 
>> On 20 Nov 2017, at 03:16, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Hi all,
>> 
>> As I mentioned on a couple other threads, I’ve been working on improving Swift interoperability with Python.  I have two pitches out: one to improve Python member lookup and one to improve calls to Python values.  While those proposals are important, I think it is also useful to see what can be accomplished with Swift today.
>> 
>> To show you how far we can get, here is a Swift playground (tested with Xcode 9) that has an example interoperability layer, and a tutorial for using it.  If you’re interested in the pitches, or in Python, please check it out:
>> 
>> <PythonInterop.playground.zip>
>> 
>> In addition to showing how far the interop can go today (which is really quite far) it shows what the future will look like assuming the member lookup and call issues are resolved.  To reiterate what I said on the pitch threads, I am not attached at all to the details of the two pitches themselves, I simply want the problems they address to be solved.
>> 
>> Finally, of course I also welcome questions and feedback on the actual approach, naming, and other suggestions to improve the model!  Thanks,
>> 
>> -Chris
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171120/f570de23/attachment.html>


More information about the swift-evolution mailing list