> 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.


swift-evolution mailing list

Reply via email to