> On Nov 1, 2017, at 21:13, Chris Lattner via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>> On Nov 1, 2017, at 3:20 AM, Richard Wei <rxr...@gmail.com 
>> <mailto:rxr...@gmail.com>> wrote:
>>>> 
>>>> 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!
>>> 
>>> Requiring ‘try’ on every statement is annoying, but not having the ability 
>>> to catch python exceptions is annoying too. We could probably make python 
>>> exception handling an opt-in feature. For example:
>>> 
>>> try Python.do {
>>>     let a = np.array([1, 2, 3])
>>>     let b = np.array([[2], [4]])
>>>     print(a.dot(b)) // matrix mul with incompatible shapes
>>> }
>>> catch let error as PythonException {
>>>     // Handle PythonError.valueError(“objects are not aligned”)
>>> }
>> 
>> To correct my example:
>> 
>> do {
>>     try Python.do {
>>         let a = np.array([1, 2, 3])
>>         let b = np.array([[2], [4]])
>>         print(a.dot(b)) // matrix mul with incompatible shapes
>>     }
>> }
>> catch let error as PythonException {
>>     // Handle PythonError.valueError(“objects are not aligned”)
>> }
>> 
>> Maybe ‘Python.do {}’ should be called something like ‘Python.safely {}’.
> 
> That’s a super interesting way to model this.  I’ll need to ponder on it 
> more, but  it is certainly a nice ergonomic solution.
> 
> Question though: how does it work?  Say the first np.array call threw a 
> python exception:
> 
>> try Python.do {
>>         let a = np.array([1, 2, 3])
>>         let b = np.array([[2], [4]])
>>         print(a.dot(b)) // matrix mul with incompatible shapes
>>     }
> 
> 
> We can definitely make the python glue code notice it, catch it and squirrel 
> it away somewhere, but without compiler hacks we couldn’t make it jump out of 
> the closure.  This means that np.array would have to return something, and 
> the calls below it would still execute, or am I missing something?

We make PythonObjects internally nullable (only in the exception-caught state). 
The second np.array would just return a null PythonObject.

To be specific, we define three states in the python overlay:
- Normal state: PythonObjects are guaranteed to be non-null. Any exception 
traps.
- Exception-catching state: PythonObjects are still guaranteed to be non-null. 
Any exception triggers the exception-caught state.
- Exception-caught state: PythonObjects are nullable — all python expressions 
return a null PythonObject.

The exception-catching state is entered during the execution of Python.do’s 
body.

-Richard

> 
> -Chris
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to