There's surprisingly little information about Cython interoperability with Cocoa/Mac applications. It's might be linkable if the app can embed Python.
-- C. Keith Ray * https://leanpub.com/wepntk <- buy my book? * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf * http://agilesolutionspace.blogspot.com/ > On Oct 29, 2017, at 4:00 PM, Chris Lattner <[email protected]> wrote: > > >> On Oct 29, 2017, at 3:23 PM, C. Keith Ray <[email protected]> wrote: >> >> It would be really nice if Cython code could be linked into iOS and Mac apps >> written in Swift or Objective-C. >> >> http://cython.org > > Isn’t that possible today, at least on the Mac? > > -Chris > > >> >> -- >> C. Keith Ray >> Senior Software Engineer / Trainer / Agile Coach >> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf >> >> >> >>>> On Oct 29, 2017, at 1:34 PM, Chris Lattner via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> >>>>> On Oct 29, 2017, at 8:23 AM, Chris Lattner via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>>> On Oct 29, 2017, at 4:04 AM, Lukas Stabe <[email protected]> wrote: >>>>>> >>>>>> On 28. Oct 2017, at 23:10, Chris Lattner via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> >>>>>> … 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. >>>>> >>>>> That sounds like a very interesting prospect. Do you think it would make >>>>> sense to make the language features that facilitate this (dynamic >>>>> dispatch of method calls, property accesses, subscript and ARC) available >>>>> to Swift classes annotated in some way, so that interop like this can be >>>>> implemented as a library without special treatment by the Swift compiler? >>>>> This could also enable more dynamic DSL like features. >>>> >>>> I haven’t explored enough of the design space to be sure, but I’d want to >>>> make sure that a library version of this could be done without giving up >>>> ergonomics of the result. If you were interested in being able to interop >>>> with other languages that are dynamically typed and reference counted, >>>> then something like this could be possible in principle: >>> >>> Thinking about the Perl case makes it clear to me that this should not be >>> built into the compiler as a monolithic thing. Perl supports several >>> different types (SV/AV/HV) which represent different concepts (scalars, >>> arrays, hashes) so baking it all together into one thing would be the wrong >>> way to map it. In fact, the magic we need is pretty small, and seems >>> generally useful for other things. Consider a design like this: >>> >>> >>> // not magic, things like Int, String and many other conform to this. >>> protocol Pythonable { >>> init?(_ : PythonObject) >>> func toPython() -> PythonObject >>> } >>> >>> // Not magic. >>> struct PythonObject : /*protocols below*/ { >>> var state : UnsafePointer<PyObject> >>> >>> subscript(_ : Pythonable…) -> PythonObject { >>> ... >>> } >>> } >>> >>> // Magic, must be on the struct definition. >>> // Could alternatively allow custom copy/move/… ctors like C++. >>> protocol CustomValueWitnessTable { >>> static func init(..) >>> static func copy(..) >>> static func move(..) >>> static func destroy(..) >>> } >>> >>> // Magic, allows anyobject-like member lookup on a type when lookup >>> otherwise fails. >>> protocol DynamicMemberLookupable { >>> associatedtype MemberLookupResultType >>> func dynamicMemberLookup(_ : String) -> MemberLookupResultType >>> } >>> >>> // Magic, allows “overloaded/sugared postfix ()”. >>> protocol CustomCallable { >>> func call( …) >>> } >>> >>> The only tricky thing about this is the call part of things. At least in >>> the case of python, we want something like this: >>> >>> foo.bar(1, 2, a: x, b: y) >>> >>> to turn into: >>> foo.dynamicMemberLookup(“bar”).call(1, 2, kwargs: [“a”:x, “b”:y]) >>> >>> We don’t want this to be a memberlookup of a value that has “bar” as a >>> basename and “a:” and “b:” as parameter labels. >>> >>> -Chris >>> >>>> >>>> protocol DynamicDispatchable { // Protocol is “magic" known by the >>>> compiler. >>>> func retain() >>>> func release() >>>> func memberLookup(_ : String) -> Self >>>> func subscript<T>(_ : T) -> Self >>>> func call(_ args: [Self]) -> Self >>>> } >>>> >>>> module Python { >>>> struct Object : DynamicDispatchable { >>>> var state : UnsafePointer<PyObject> >>>> >>>> func retain() { >>>> INCREF(self) >>>> } >>>> >>>> func memberLookup(_ : String) -> Object { >>>> PyObject_GetAttrString(…) >>>> } >>>> etc >>>> } >>>> >>>> module Perl5 { >>>> struct Object : DynamicDispatchable { >>>> var state : UnsafePointer<SV> >>>> >>>> func retain() { >>>> SvREFCNT_inc(self) >>>> } >>>> …. >>>> >>>> >>>> >>>> Are there other uses for such a thing? >>>> >>>> -Chris >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
