On Dec 5, 2017, at 11:51 PM, Jonathan Hull <jh...@gbis.com> wrote:
> Ok, I have changed my mind about the need for a marker, and will accept the
> proposal as-is. I realized that these dynamic member lookup types can just
> be made inner types, and so I can easily create the .dynamic behavior in my
> own code if I want under the current proposal. I also realized that
> requiring a marker would screw up the proxy use-case of this.
>
> I do still have a couple of questions I am confused on:
Hi Jonathan,
I’d suggest taking a look at the playground that I periodically send out to
swift-evolution showing the current state of the python interop. I just sent
an update to the "Python Interop with Swift 4+” thread just now. It works with
unmodified Xcode 9, but includes comments showing what code could look like
with the proposal in question.
> 1) How do operators work with this? I saw you give an example of a+b for
> python types, but I don’t see where either proposal bridges operators. (I
> could easily have missed it though)
As Magnus points out, Swift 4 already supports overloading operators with
dynamic behavior. In the case of the playground, it looks like this:
public func +(lhs: PyVal, rhs: PyVal) -> PyVal {
return lhs.call(member: "__add__", args: rhs)
}
This has all the “bad behavior” that people are concerned about: it could fail
at runtime. Despite the claims, Swift does not actually make an effort to
prevent this, and that is an intentional part of its design.
> 2) What if I need two separate python libraries? The code says ‘let np =
> Python.import(“numpy”)’. Are we supposed to make a separate variable for
> each import?
Yes, that is traditional for python, which would typically look like:
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
and the playground already supports (with no language extensions):
let np = Python.import(“numpy”)
let pd = Python.import(“pandas”)
let plt = Python.import(“matplotlib.pyplot”)
It turns out that languages everywhere have standardized on starting with a
block of imports :-)
> 3) How will inter-op between Swift types and Python types work? It looks
> like you are just passing strings and integer constants to python functions.
> Do they get converted automatically, or do we have to explicitly convert
> them? I am guessing this is using expressibleBy___ to work?
PyVal conforms to all of the ExpressibleBy protocols, so you can use literals
with it freely. You need an explicit (failable) conversion from a PyVal to Int
(and other types that are PythonConvertible), and can use an explicit
non-failable conversion from Int to PyVal if it is a variable.
The playground has a tutorial page which shows all this in action.
-Chris
>
> Also, I would still really like to see a different coloring/styling for
> methods which fall down to this protocol.
>
> Thanks,
> Jon
>
>
>
>> On Dec 4, 2017, at 7:30 PM, Chris Lattner via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>>> On Dec 4, 2017, at 5:22 PM, Joe DeCapo via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>> The first one, has no static type info, no compile time checking, it's not
>>>> self documenting, no type inference so people will be forced to use a
>>>> dynamic reference at the call site to store the result, leading to more
>>>> type loss, and all this spirals down.
>>>> I'm already starting to fear dynamic.
>>>> Edit: The danger has passed (Phew!) ... and dynamic wasn't been abused
>>>> after all, no need to down vote me after 3 years :)
>>>
>>> From what I can gather, `dynamic` is used when declaring types, but there's
>>> no indication at call sites that what is being invoked is dynamic. And it
>>> even allows for casting basically anything to the `dynamic` type.
>>>
>>> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/dynamic
>>>
>>> So here we have a language community that was (is?) very vocal about
>>> caution when it comes to type inference with `var`, but seems to have
>>> accepted the validity of `dynamic`. This seems to show that at least one
>>> community has absorbed this sort of change (arguably a more "dangerous"
>>> version than what is being proposed here) with no real issues.
>>
>> Right. dynamic in C# is far broader (and more “dangerous”) than what I’m
>> proposing. That said, because there have been absolutely zero specific
>> examples of the sorts of harm DynamicMemberLookup could cause, it is
>> difficult to speculate about exactly which boogieman people are afraid of.
>>
>>> So I have a few questions:
>>>
>>> - Would it be enough to require annotation of the dynamic nature of a type
>>> at the declaration sites, if that still means the call sites aren't
>>> explicitly annotated?
>>
>> It is impossible to solve a problem if it cannot be explained in enough
>> detail to provide examples. Personally, I don’t see the problem at all.
>>
>>> - Why do some think the Swift community would be more at risk of abuse of
>>> this feature than the C# community seems to have been?
>>
>>
>> People are making bizarre claims about what the spirit of Swift is,
>> informing me of things which are obviously not true, and ignoring the
>> evidence I present to them. This is doubly humorous given that I have a
>> fairly good sense for the design balance and tradeoffs of existing features
>> in Swift today, along with detailed rationale for why they were added, when,
>> and all of the discussion that backed them. I chalk this up to the fear of
>> the unknown or perhaps a mistrust for the peers these people work with.
>>
>> My goal is to make the design and proposal writeup as good as possible, and
>> the fear mongering about abuse has led me to add several options for further
>> narrowing the potential for abuse, including to the point of requiring every
>> new adoptee to go through the Swift evolution process for review. During
>> the review period for DynamicMemberLookup, people who carry these concerns
>> are welcome to +1 one or more of those.
>>
>> I personally am far more interested in getting to the bottom of Doug’s
>> concerns - it isn’t clear to me what exactly his preferred direction
>> actually is, but that discussion is based on engineering tradeoffs and may
>> well lead to a change to the proposal or a complete change in direction.
>>
>> -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
