> 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. /Magnus _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
