I tried to send a response to this earlier today but it apparently didn’t get
out. If it did, then I apologize in advance for the dupe:
> On Oct 30, 2017, at 10:47 PM, Douglas Gregor <dgre...@apple.com> wrote:
>>>> // not magic, things like Int, String and many other conform to this.
>>>> protocol Pythonable {
>>>> init?(_ : PythonObject)
>>>> func toPython() -> PythonObject
>>>> }
>>>
>>> It’s not magic unless you expect the compiler or runtime to help with
>>> conversion between Int/String/etc. and PythonObject, as with
>>> _ObjectiveCBridgeable.
>>
>> Right, as I said above “not magic”. The conformances would be manually
>> implemented in the Python overlay. This provides a free implicit conversion
>> from "T -> Pythonable” for the T’s we care about, and a failable init from
>> Python back to Swift types.
>
> Note that, under this scheme,
>
> let p: Pythonable = 17
> let i: Int = p as! i
>
> will work if Int is Pythonable, but not when p comes back from Python.
Right. I don't expect users to traffic in the Pythonable type, it would be
something that is used internally by the Python overlay. The only time I'd
expect them to see it is when they want to make one of their types Pythonable
(which would be rare, but needs to be possible).
>> I can think of two things that could tip the scale of the discussion:
>>
>> a) The big question is whether we *want* the ability to write custom
>> rule-of-5 style behavior for structs, or if we want it to only be used in
>> extreme cases (like bridging interop in this proposal). If we *want* to
>> support it someday, then adding proper “safe” support is best (if possible).
>> If we don’t *want* people to use it, then making it Unsafe and ugly is a
>> reasonable way to go.
>>
>> b) The ownership proposal is likely to add deinit's to structs. If it also
>> adds explicit move initializers, then it is probably the right thing to add
>> copy initializers also (and thus go with approach #2). That said, I’m not
>> sure how the move initializers will be spelled or if that is the likely
>> direction. If it won’t add these, then it is probably better to go with
>> approach #1. John, what do you think?
>>
>>> Presumably, binding to Python is going to require some compiler
>>> effort—defining how it is that Python objects are
>>> initialized/copied/moved/destroyed seems like a reasonable part of that
>>> effort.
>>
>> Actually no. If we add these three proposals, there is no other python (or
>> perl, etc…) specific support needed. It is all implementable in the overlay.
>
> Support for working with Python objects would be implementable in the
> overlay, but the result isn’t necessarily ergonomic (e.g., my “as!” case from
> a Python-generated integer object to Int, shown above). That might be fine!
> More comments on this below.
Yeah, I don't think that matters. The preferred way to do this is to use:
Int(somePythonValue)
which would be a failable conversion. somePythonValue would be a PythonObject
(the struct) not "Pythonable"
>>>> // Magic, allows anyobject-like member lookup on a type when lookup
>>>> otherwise fails.
>>>> protocol DynamicMemberLookupable {
>>>> associatedtype MemberLookupResultType
>>>> func dynamicMemberLookup(_ : String) -> MemberLookupResultType
>>>> }
>>>
>>> AnyObject lookup looks for an actual declaration on any type anywhere. One
>>> could extend that mechanism to, say, return all Python methods and assume
>>> that you can call any Python method with any PythonObject instance.
>>> AnyObject lookup is fairly unprincipled as a language feature, because
>>> there’s no natural scope in which to perform name lookup, and involves
>>> hacks at many levels that don’t always work (e.g., AnyObject lookup…
>>> sometimes… fails across multiple source files for hard-to-explain reasons).
>>> You’re taking on that brokenness if you expand AnyObject lookup to another
>>> ecosystem.
>>
>> Yeah, sorry, that’s not what I meant:
>
> (Good)
Also, for sake of discussion, we’d have to figure out what the type of
MemberLookupResultType would be for Python. I can see several choices:
1) Make it return a "PythonObject!”
2) Make it strict, returning a PythonObject or trapping.
3) Make PythonObject itself nullable internally and return a null PythonObject.
#1 matches Python semantics directly, because it allows clients who care to
check, but those who don't can ignore it. The only problem I anticipate is
that it will break things like:
let x = foo.bar
let y = x.thing // fails, because x implicitly promoted to PythonObject?
#3 is gross and cuts against lots of things in Swift (recall when UnsafePointer
itself was implicitly nullable, lets not go back to those bad old days). I
think that #2 is the least bad tradeoff.
>> Right, something like this could definitely work, but keep in mind that the
>> Swift compiler knows nothing about Python declarations.
>>
>> Perhaps the most straight-forward thing would be to support:
>>
>> protocol CustomCallable {
>> func call(…arg list as array and kw args...)
>> func callMember(_ : String, …otherstuffabove...)
>> }
>>
>> Given this, the compiler could map:
>>
>> pythonThing(42) -> pythonThing.call([42])
>> pythonThing.method(a: 42) -> pythonThing.callMember(“method”, kwargs:
>> [“a”: 42])
>>
>> This is the simplest way to map the Swift semantics (where kw args are part
>> of compound lookups) into the Python world.
>
> Okay, I agree that this gets Swift syntax into a call to the Python
> interpreter fairly quickly. Over-architecting for the sake of discussion:
>
> protocol CustomCallable {
> associatedtype CustomArgument
> associatedtype CustomNominal
> associatedtype CustomResult
>
> func callMember(self: CustomNominal, functionName: String, arguments:
> [(String, CustomArgument)]) throws -> CustomResult
> // something for class/static members
> }
>
> But this is *all* dynamic, even when one could map much of Python’s type
> information into Swift. For example, let’s take this:
Yes, something like this is what I had in mind, but I think that functionName
should only be required to be StringLiteralConvertible (no need to actually
synthesize a real swift string).
Since you bring it up, Python exceptions will be annoying - As with other
languages, Python can throw from an arbitrary expression. Modeling everything
as throws in Swift would be super-annoying and unergonomic for the programmer,
because we'd require 'try' everywhere. Thoughts on what to do about that are
welcome!
>
> class Dog:
>
> def __init__(self, name):
> self.name = name
> self.tricks = [] # creates a new empty list for each dog
>
> def add_trick(self, trick):
> self.tricks.append(trick)
>
> With your don’t-modify-the-compiler approach, how can I create a Dog instance
> and add a trick? I probably need to look up the class by name, call __init__
> manually, etc.
>
> let dogClass = python_getClassByName(“Dog”) // implemented in the Python
> “overlay’, I guess
> let dog = python_createInstance(dogClass) // implemented in the Python
> “overlay’, I guess
> dog.__init__(“Brianna”) // uses CustomCallable’s callMember
> dog.add_trick(“Roll over”) // uses CustomCallable’s callMember
I-am-not-a-python-expert, but I'd expect this to work:
let dogModule = Python.import("DogModule")
dogModule.Dog("jckarter").add_trick("SILGenGen”)
let dog = dogModule.Dog(“Brianna”)
dog.add_trick(“Roll over)
or equivalently:
let Dog = Python.import(“DogModule.Dog")
Dog("jckarter").add_trick("SILGenGen”)
let dog = Dog(“Brianna”)
dog.add_trick(“Roll over)
Seems pretty nice to me, with zero “Swift compiler knowledge of Python”
required.
> With compiler integration,
>
> class Dog : PythonObject {
> init(_ name: Pythonable)
> func add_trick(_ trick: Pythonable)
> }
Something like this is possible, but would be substantially more work, be
substantially more invasive, and would set the precedent that every other
dynamic language would get support hacked directly into Swift. The only reason
I can see this being useful is if we wanted to support the optional typing
annotations in Python. While this would be "nice to have", I think the
cost/benefit tradeoff involved is totally wrong for Swift.
> With either the true “Python importer” solution or this code-generation
> solution, you at least get some level of code completion and basic sanity
> checking “for free”. In other words, you get some of the benefits of having a
> statically-type-checked language while still working on dynamic Pythonable
> types.
We don't need to make Swift better at Python than Python itself is :-)
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
