It could work, but is a much worse approach IMO. The proposal discusses it here: https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#motivation-and-context <https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#motivation-and-context> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#direct-language-support-for-python-and-all-the-other-languages <https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#direct-language-support-for-python-and-all-the-other-languages>
Doug has been suggesting similar directions upthread, when he has a chance to respond to my questions, I’ll do a detailed comparison of the approaches. -Chris > On Dec 4, 2017, at 10:05 AM, Dave DeLong <sw...@davedelong.com> wrote: > > Hi Chris, > > We do the Swift integration with Objective-C via modules. Why wouldn’t that > approach work with Python? Or if it would, why would we favor this dynamic > member lookup over importing a Python API via a module? > > Dave > >> On Nov 26, 2017, at 11:04 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I’d like to formally propose the inclusion of user-defined dynamic member >> lookup types. >> >> Here is my latest draft of the proposal: >> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 >> https://github.com/apple/swift-evolution/pull/768 >> >> An implementation of this design is available here: >> https://github.com/apple/swift/pull/13076 >> >> The implementation is straight-forward and (IMO) non-invasive in the >> compiler. >> >> -Chris >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
