[Cython] [PATCH] Turn std::invalid_argument into ValueError

Hopefully I am doin' it right. invalid_argument seems like the correct
analogue to ValueError.

GMail shouldn't mangle this, but it wouldn't be the first time.

~ C.

--- Compiler/ExprNodes.py.back  2010-09-02 23:57:02.000000000 -0700
+++ Compiler/ExprNodes.py       2010-09-02 23:46:30.000000000 -0700
 <at>  <at>  -7028,6 +7028,9  <at>  <at> 
      ; // let the latest Python exn pass through and ignore the current one
    else
      throw;
+  } catch (const std::invalid_argument& exn) {
+    // Catch invalid_argument explicitly and raise a ValueError
+    PyErr_SetString(PyExc_ValueError, exn.what());
  } catch (const std::out_of_range& exn) {
    // catch out_of_range explicitly so the proper Python exn may be raised
    PyErr_SetString(PyExc_IndexError, exn.what());

--
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude@...>

Re: [Cython] [PATCH] Turn std::invalid_argument into ValueError

On Fri, Sep 3, 2010 at 12:03 AM, Corbin Simpson
<mostawesomedude@...> wrote:
> Hopefully I am doin' it right. invalid_argument seems like the correct
> analogue to ValueError.

Yes. Thanks!

> GMail shouldn't mangle this, but it wouldn't be the first time.

Could you send it as an attachment? Also, if you use hg to make the
patch (type make repo to upgrade cython directory to the full hg
repository) it will have metadata such as a changelog entry and
username attached, which would be preferable.

- Robert

> ~ C.
>
> --- Compiler/ExprNodes.py.back  2010-09-02 23:57:02.000000000 -0700
> +++ Compiler/ExprNodes.py       2010-09-02 23:46:30.000000000 -0700
>  <at>  <at>  -7028,6 +7028,9  <at>  <at> 
>       ; // let the latest Python exn pass through and ignore the current one
>     else
>       throw;
> +  } catch (const std::invalid_argument& exn) {
> +    // Catch invalid_argument explicitly and raise a ValueError
> +    PyErr_SetString(PyExc_ValueError, exn.what());
>   } catch (const std::out_of_range& exn) {
>     // catch out_of_range explicitly so the proper Python exn may be raised
>     PyErr_SetString(PyExc_IndexError, exn.what());

Re: [Cython] [PATCH] Turn std::invalid_argument into ValueError

On Fri, Sep 3, 2010 at 9:05 AM, Robert Bradshaw
<robertwb@...> wrote:
> Could you send it as an attachment? Also, if you use hg to make the
> patch (type make repo to upgrade cython directory to the full hg
> repository) it will have metadata such as a changelog entry and
> username attached, which would be preferable.

Whoo, hg. First time using it. It's like git and svn, so I think I did it right.

Is there ongoing work on the C++ support? There's still a couple
holes, for example wrapping this is still not right and I can't figure
out how to mod Cython appropriately.

template <typename T, int number> class SomeClass;

Since this is currently my Easy Path (the Hard Path involves modding
Panda3D to compile with C++0x) I'm willing to fix Cython bugs to make
it happen.

~ C.

--

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude@...>

On Fri, Sep 3, 2010 at 9:05 AM, Robert Bradshaw

Re: [Cython] [PATCH] Turn std::invalid_argument into ValueError

On Fri, Sep 3, 2010 at 1:31 PM, Corbin Simpson
<mostawesomedude@...> wrote:
> On Fri, Sep 3, 2010 at 9:05 AM, Robert Bradshaw
> <robertwb@...> wrote:
>> Could you send it as an attachment? Also, if you use hg to make the
>> patch (type make repo to upgrade cython directory to the full hg
>> repository) it will have metadata such as a changelog entry and
>> username attached, which would be preferable.
>
> Whoo, hg. First time using it. It's like git and svn, so I think I did it right.

Looks good. Thanks! Pushed.

> Is there ongoing work on the C++ support? There's still a couple
> holes, for example wrapping this is still not right and I can't figure
> out how to mod Cython appropriately.
>
> template <typename T, int number> class SomeClass;

Int templates are still not supported, but you're not the first to
request them. C++ support is in no ways complete, and there's still a
lot of low-hanging fruit, but I don't think anyone is actively working
on it right now (other than fixing a bug here and there).

> Since this is currently my Easy Path (the Hard Path involves modding
> Panda3D to compile with C++0x) I'm willing to fix Cython bugs to make
> it happen.

That would be great. Please feel free to ping the list if you have any
questions about how things work.

Re: [Cython] C string literals

Carl Witty, 25.08.2010 22:21:
> On Wed, Aug 25, 2010 at 12:15 PM, Stefan Behnel wrote:
>> Lisandro Dalcin, 25.08.2010 20:28:
>>> When trying to cythonize my code using the -3 flag, I got many errors
>>> like the one below:
>>>
>>> Error converting Pyrex file to C:
>>> ------------------------------------------------------------
>>> ...
>>>       if not (<int>PetscInitializeCalled): return
>>>       if (<int>PetscFinalizeCalled): return
>>>       # deinstall custom error handler
>>>       ierr = PetscPopErrorHandlerPython()
>>>       if ierr != 0:
>>>           fprintf(stderr, "PetscPopErrorHandler() failed "
>>>                          ^
>>> ------------------------------------------------------------
>>>
>>> /u/dalcinl/Devel/petsc4py-dev/src/PETSc/PETSc.pyx:307:24: Unicode
>>> literals do not support coercion to C types other than Py_UNICODE.
>>
>> Right, the parser reads the literal as unicode string here before type
>> analysis figures out that it's really meant to be a bytes literal.
>>
>> This will be hard to change as recovering the original bytes literal is
>> impossible once it's converted to a unicode string (remember that you can
>> use arbitrary character escape sequences in the literal). So I'm leaning
>> towards keeping this as an error. After all, Unicode string literals is one
>> of the things that a user explicitly requests with the -3 switch.
>

Re: [Cython] C string literals

Stefan Behnel, 04.09.2010 17:29:
> Carl Witty, 25.08.2010 22:21:
>> On Wed, Aug 25, 2010 at 12:15 PM, Stefan Behnel wrote:
>>> Lisandro Dalcin, 25.08.2010 20:28:
>>>> When trying to cythonize my code using the -3 flag, I got many errors
>>>> like the one below:
>>>>
>>>> Error converting Pyrex file to C:
>>>> ------------------------------------------------------------
>>>> ...
>>>>        if not (<int>PetscInitializeCalled): return
>>>>        if (<int>PetscFinalizeCalled): return
>>>>        # deinstall custom error handler
>>>>        ierr = PetscPopErrorHandlerPython()
>>>>        if ierr != 0:
>>>>            fprintf(stderr, "PetscPopErrorHandler() failed "
>>>>                           ^
>>>> ------------------------------------------------------------
>>>>
>>>> /u/dalcinl/Devel/petsc4py-dev/src/PETSc/PETSc.pyx:307:24: Unicode
>>>> literals do not support coercion to C types other than Py_UNICODE.
>>>
>>> Right, the parser reads the literal as unicode string here before type
>>> analysis figures out that it's really meant to be a bytes literal.
>>>
>>> This will be hard to change as recovering the original bytes literal is
>>> impossible once it's converted to a unicode string (remember that you can
>>> use arbitrary character escape sequences in the literal). So I'm leaning
>>> towards keeping this as an error. After all, Unicode string literals is one
>>> of the things that a user explicitly requests with the -3 switch.

Re: [Cython] other issue with cython -3

Stefan Behnel, 25.08.2010 22:09:
> Lisandro Dalcin, 25.08.2010 21:57:
>> On 25 August 2010 16:16, Stefan Behnel wrote:
>>> Lisandro Dalcin, 25.08.2010 21:00:
>>>> $ cython -3 tmp.pyx
>>>>
>>>> Error converting Pyrex file to C:
>>>> ------------------------------------------------------------
>>>> ...
>>>> cdef str a = "abc"
>>>>                ^
>>>> ------------------------------------------------------------
>>>>
>>>> /u/dalcinl/tmp/tmp.pyx:1:13: Cannot convert Unicode string to 'str'
>>>> implicitly. This is not portable and requires explicit encoding.
>>>
>>> Same thing I said before: if you request unicode string literals, you get
>>> unicode literals.
>>
>> But in Python 3, the the Python-level 'str' type actually  is an unicode string!
>
> Ah, right, I missed that. Yes, I think it makes sense to statically
> associate 'str' with 'unicode' on -3.

Hmm, that's tricky, though. We can't change the Builtin scope itself as 
that's a global thing, so we somehow need to intercept lookups of 'str' 
before hitting the builtin scope and replace it by 'unicode', so that both 
the 'cdef str' declaration work as well as Python references to the builtin 
type. Ugly...

Re: [Cython] other issue with cython -3

Stefan Behnel, 04.09.2010 21:30:
> Stefan Behnel, 25.08.2010 22:09:
>> Lisandro Dalcin, 25.08.2010 21:57:
>>> On 25 August 2010 16:16, Stefan Behnel wrote:
>>>> Lisandro Dalcin, 25.08.2010 21:00:
>>>>> $ cython -3 tmp.pyx
>>>>>
>>>>> Error converting Pyrex file to C:
>>>>> ------------------------------------------------------------
>>>>> ...
>>>>> cdef str a = "abc"
>>>>>                 ^
>>>>> ------------------------------------------------------------
>>>>>
>>>>> /u/dalcinl/tmp/tmp.pyx:1:13: Cannot convert Unicode string to 'str'
>>>>> implicitly. This is not portable and requires explicit encoding.
>>>>
>>>> Same thing I said before: if you request unicode string literals, you get
>>>> unicode literals.
>>>
>>> But in Python 3, the the Python-level 'str' type actually  is an unicode string!
>>
>> Ah, right, I missed that. Yes, I think it makes sense to statically
>> associate 'str' with 'unicode' on -3.
>
> Hmm, that's tricky, though. We can't change the Builtin scope itself as
> that's a global thing, so we somehow need to intercept lookups of 'str'
> before hitting the builtin scope and replace it by 'unicode', so that both
> the 'cdef str' declaration work as well as Python references to the builtin
> type. Ugly...

Re: [Cython] C string literals

On Sat, Sep 4, 2010 at 8:29 AM, Stefan Behnel <stefan_ml@...> wrote:
> Carl Witty, 25.08.2010 22:21:
>> On Wed, Aug 25, 2010 at 12:15 PM, Stefan Behnel wrote:
>>> Lisandro Dalcin, 25.08.2010 20:28:
>>>> When trying to cythonize my code using the -3 flag, I got many errors
>>>> like the one below:
>>>>
>>>> Error converting Pyrex file to C:
>>>> ------------------------------------------------------------
>>>> ...
>>>>       if not (<int>PetscInitializeCalled): return
>>>>       if (<int>PetscFinalizeCalled): return
>>>>       # deinstall custom error handler
>>>>       ierr = PetscPopErrorHandlerPython()
>>>>       if ierr != 0:
>>>>           fprintf(stderr, "PetscPopErrorHandler() failed "
>>>>                          ^
>>>> ------------------------------------------------------------
>>>>
>>>> /u/dalcinl/Devel/petsc4py-dev/src/PETSc/PETSc.pyx:307:24: Unicode
>>>> literals do not support coercion to C types other than Py_UNICODE.
>>>
>>> Right, the parser reads the literal as unicode string here before type
>>> analysis figures out that it's really meant to be a bytes literal.
>>>
>>> This will be hard to change as recovering the original bytes literal is
>>> impossible once it's converted to a unicode string (remember that you can
>>> use arbitrary character escape sequences in the literal). So I'm leaning
>>> towards keeping this as an error. After all, Unicode string literals is one
>>> of the things that a user explicitly requests with the -3 switch.

Re: [Cython] C string literals

Robert Bradshaw, 04.09.2010 22:04:
> How about we parse the literals as unicode strings, and if used in a
> bytes context we raise a compile time error if any characters are
> larger than a char?

Can't work because you cannot recover the original byte sequence from a 
decoded Unicode string. It may have used escapes or not, and it may or may 
not be encodable using the source code encoding.

Stefan