<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 4, 2017, at 10:08 AM, Benjamin G via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: SourceCodePro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">1_ From what i understood from this discussion (please correct me if i'm wrong) python code is already callable from swift right now, without any modification to the compiler, but then the syntax to *some* very generic python function would just not be really pretty. If it's just library calls, we could just wrap those calls into pretty functions for our needs, but then :<span class="Apple-converted-space"> </span></span></div></blockquote></div><br class=""><div class="">I think it's worthwhile to add this syntactic sugar to make wrapper libraries easier to write and reason about. From Chris's example playground:</div><div class=""><br class=""></div><div class=""><div class=""><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; background-color: rgb(255, 255, 255);" class=""><span style="color: rgb(186, 45, 162);" class="">let</span> d = <span style="color: rgb(79, 129, 135);" class="">np</span>.call(member: <span style="color: rgb(209, 47, 27);" class="">"array"</span>, args: Python.array(<span style="color: rgb(39, 42, 216);" class="">6</span>, <span style="color: rgb(39, 42, 216);" class="">7</span>, <span style="color: rgb(39, 42, 216);" class="">8</span>),</div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; background-color: rgb(255, 255, 255);" class=""> kwargs: [(<span style="color: rgb(209, 47, 27);" class="">"dtype"</span>, <span style="color: rgb(209, 47, 27);" class="">"i2"</span>)])</div></div><div style="margin: 0px; font-stretch: normal; font-size: 13px; line-height: normal; background-color: rgb(255, 255, 255);" class=""><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(0, 132, 0);" class="">// Python: d = np.array([1, 2, 3], dtype="i2")</div><div style="margin: 0px; font-stretch: normal; line-height: normal; color: rgb(0, 132, 0);" class="">// Future Swift: let d = np.array([6, 7, 8], dtype: "i2")</div></div></div><div class=""><br class=""></div><div class="">It's far easier (at least for me) to read the sugared Swift version and understand what it is doing than how it's currently required to be written.</div><div class=""><br class=""></div><div class="">I'm sure it's true that people coming from a background in a dynamic language will initially write "bad" Swift code. When I first started writing Python, I wrote it like Swift/Objective-C/Bash. But eventually I learned more of the common idioms in Python and rewrote my code to use those idioms. This is a bridge to allow easy access to the vast number of libraries that currently exist in those dynamic language domains, and to ease the transition of the multitudes of those programmers into Swift.</div><div class=""><br class=""></div><div class="">From everything I've seen in the Swift community so far, I have faith that we collectively won't abuse this feature to the point that it poisons what Swift has achieved so far. And I'm not against some type of "guardrails" that help prevent unintentional misuse, but I'd like for it not to be so much as to be punishing to those that want to make use of the proposed features.</div></body></html>