> 6 Dec. 2017 16:51 Jonathan Hull via swift-evolution 
> <swift-evolution@swift.org> wrote:
> Ok, I have changed my mind about the need for a marker, and will accept the 
> proposal as-is.  I realized that these dynamic member lookup types can just 
> be made inner types, and so I can easily create the .dynamic behavior in my 
> own code if I want under the current proposal.  I also realized that 
> requiring a marker would screw up the proxy use-case of this.
> I do still have a couple of questions I am confused on:
> 1) How do operators work with this?  I saw you give an example of a+b for 
> python types, but I don’t see where either proposal bridges operators. (I 
> could easily have missed it though)

Operators can be bridged using the existing Swift mechanisms, in this case 
operator overloading, so the proposal does not need to address operators.

> 2) What if I need two separate python libraries?  The code says ‘let np = 
> Python.import(“numpy”)’.  Are we supposed to make a separate variable for 
> each import?
> 3) How will inter-op between Swift types and Python types work?  It looks 
> like you are just passing strings and integer constants to python functions. 
> Do they get converted automatically, or do we have to explicitly convert 
> them?  I am guessing this is using expressibleBy___ to work?

All of these will be up to the Python bridge implementation or implementations. 
This proposal is not a proposal of how to bridge Python and Swift, it is only 
enabling (not requiring) a decent syntax for these kinds of bridges.


swift-evolution mailing list

Reply via email to