<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Oct 28, 2017, at 9:45 AM, Maxim Veksler via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div dir="rtl" class=""><div dir="ltr" class="">Hey Guys,<br clear="all" class=""></div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">The big data and machine learning world is dominated by Python, Scala an R. <br class=""></div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">I'm a Swifter by heart, but not so much by tools of trait. </div></div></div></blockquote><div><br class=""></div><div>Hi Max,</div><div><br class=""></div><div>I’m very interested in this topic, with a specific focus on Python. It isn’t the immediate thing on my priority list to deal with, but I hope that we get to push on this.</div><div><br class=""></div><div>In short, I think we should build a simple Swift/Python interop story. This sort of thing has be built numerous times for many languages (owing to Python’s great support for embed-ability), including things like PyObjC, boost.python, and many others.</div><div><br class=""></div><div>In Swift, it is straightforward to make this example (<a href="http://cs231n.github.io/python-numpy-tutorial/#numpy-arrays" class="">http://cs231n.github.io/python-numpy-tutorial/#numpy-arrays</a>) look something like this:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>let np = Python.import(“numpy”) // Returns a value of type Python.Object.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>let a = np.array([1, 2, 3])</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>print(type(a)) // Whether we want to support type(x) or use the Swift equivalent would be up for discussion of course!</div><span class="Apple-tab-span" style="white-space:pre"> </span>print(a.shape)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>print(a[0], a[1], a[2])<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>a[0] = 5<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>print(a)<div class=""><br class=""></div><span class="Apple-tab-span" style="white-space:pre"> </span>let b = np.array([[1,2,3],[4,5,6]])<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>print(b.shape)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>print(b[0, 0], b[0, 1], b[1, 0])<div><br class=""></div><div>… which is to say, exactly identical to the Python version except that new variables need to be declared with let/var. This can be done by blessing Python.Object (which is identical to “PyObject*” at the machine level) with some special dynamic name lookup behavior: Dot syntax turns into a call to PyObject_GetAttrString, subscripts turn into PyObject_GetItem, calls turn into PyObject_Call, etc. ARC would be implemented with INCREF etc.</div><div><br class=""></div><div>If we do this, the vast majority of the Python ecosystem should be directly usable from within Swift code, and the only a few major syntactic differences (e.g. ranges work differently). We would add failable inits to the primitive datatypes like Int/String/etc to convert Python.Object values into them, and add the corresponding non-failable conversions from Python.Object to those primitives.</div><div><br class=""></div><div>Overall, I think it will provide a really nice experience, and allow us to leverage the vast majority of the Python ecosystem directly in Swift code. This project would also have much more narrow impact on the Swift compiler than the ObjC importer (since it works completely differently). For a first cut, I don’t think we would have to worry about Swift classes subclassing Python classes, for example.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="rtl" class=""><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">I'd appreciate a constructive discussion on how that could be changed.</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">While R is a non goal for obvious reasons, i'd argue that since both Scala and Python are general purpose languages, taking them head to head might be a low hanging fruit.</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">To make the claim I'd like to reference to projects such as </div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class=""> - Hadoop, Spark, Hive are all huge eco-systems which are entirely JVM based.</div><div dir="ltr" class=""> - Apache Parquet, a highly efficient column based storage format for big data analytics which was implemented in Java, and C++.</div><div dir="ltr" class=""> - Apache Arrow, a physical memory spec that big data systems can use to allow zero transformations on data transferred between systems. Which (for obvious reasons) focused on JVM, to C interoperability.</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">Python's Buffer Protocol which ensures it's predominance (for the time being) as a prime candidate for data science related projects <a href="https://jeffknupp.com/blog/2017/09/15/python-is-the-fastest-growing-programming-language-due-to-a-feature-youve-never-heard-of/" target="_blank" class="">https://jeffknupp.com/blog/<wbr class="">2017/09/15/python-is-the-<wbr class="">fastest-growing-programming-<wbr class="">language-due-to-a-feature-<wbr class="">youve-never-heard-of/</a></div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">While Swift's Memory Ownership manifesto touches similar turf discussing copy on write and optimizing memory access overhead it IMHO takes a system level perspective targeting projects such as kernel code. I'd suggest that viewing the problem from an efficient CPU/GPU data crunching machine perspective might shade a different light on the requirements and use cases. </div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">I'd be happy to learn more, and have a constructive discussion on the subject.</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">Thank you,</div><div dir="ltr" class="">Max.</div><div dir="ltr" class=""> </div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">-- <br class=""></div><div class="m_6237153780122507907gmail_signature" dir="ltr"><div class="">puıɯ ʎɯ ɯoɹɟ ʇuǝs<br class=""></div></div>
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>