> On Dec 4, 2017, at 10:08 AM, Benjamin G via swift-evolution
> <[email protected]> wrote:
>
> 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
> :
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:
let d = np.call(member: "array", args: Python.array(6, 7, 8),
kwargs: [("dtype", "i2")])
// Python: d = np.array([1, 2, 3], dtype="i2")
// Future Swift: let d = np.array([6, 7, 8], dtype: "i2")
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.
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.
>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._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
