> On Dec 19, 2017, at 11:26 PM, Douglas Gregor <dgre...@apple.com> wrote: > >> Beyond that, they are small extensions with low complexity, scale to >> supporting many different dynamic languages over time, require a level of >> engineering effort that is plausible to be built, and do not require some >> sort of "executive buy in” from the Python community. > > Here’s an alternative proposal that provides a better development experience: > write a wrapper generator, in Python, that maps a Python module’s interfaces > to Swift, and provide small tie-ins to the compiler to make it fit well. Take > the example from the DynamicMemberLookup proposal:
Doug and I and the rest of the core team discussed this today, and agreed that the foreign class idea proposed isn’t necessary - the majority of the value is being provided by the generated wrapper code, and that wrapper code composes on top of the existing Python prototype with no additional language features. Given that, we’re not pursuing the ‘foreign class’ idea. That said, if wrappers are sufficient to solve the problem, that could eliminate the need for the other two proposals entirely. I’m going to explore this a bit to understand the limitations and advantages of this approach and will get back to this list (in a new thread) in a couple weeks. -Chris _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
