Re: [Cython] Recent bugs in generators
2011/4/18 Stefan Behnel : > Vitja Makarov, 18.04.2011 06:38: >> >> 2011/4/18 Stefan Behnel: >>> >>> Vitja Makarov, 17.04.2011 17:57: 3. check_yield_in_exception() >>> >>> I added this because I found a failing pyregr test that uses it (testing >>> the >>> @contextmanager decorator). >>> >>> Cython calls __Pyx_ExceptionReset when except block is done, so when yield is there no exception reset is called. I'm not sure how to fix this. >>> >>> I'm not completely sure either. >>> >>> import sys def foo(): """ >>> list(foo()) [, None] """ try: raise ValueError except ValueError: yield sys.exc_info()[0] yield sys.exc_info()[0] # exc_info is lost here >>> >>> I think (!), the difference here is that CPython actually keeps the >>> exception in the generator frame. We don't have a frame, so we have to >>> emulate it using the closure class. I guess we'll have to store away the >>> exception into the closure when we yield while an exception is being >>> handled, and restore it afterwards. Note: this is not the exception that >>> is >>> freshly *being* raised (the "_cur*" fields in the thread state), it's the >>> exception that *was* raised and is now being handled, i.e. the thread >>> state >>> fields without the "_cur", that are reflected by sys.exc_info(). >> >> Interesting difference between py2 and py3: >> >> def foo(): >> try: >> raise ValueError >> except ValueError: >> yield >> raise >> list(foo()) >> >> File "xxx.py", line 7, in >> list(foo()) >> File "xxx.py", line 6, in foo >> raise >> TypeError: exceptions must be old-style classes or derived from >> BaseException, not NoneType >> >> It seems that exception info is completely lost (tried 2.6, 2.7) and >> seems to be fixed in python3. > > Not surprising. The implementation is completely different in Py2 and Py3, > both in CPython and in Cython. It's actually much simpler in Cython under > Py3, due to better semantics and C-API support. That also implies that > there's much less Cython can do wrong in that environment. ;-) > > >> Btw exception info temps are already saved and restored between yields. > > Right, but the exc_info itself is not reset and recovered around the yield. > As I said above, generators have their own lifetime frame in CPython, and > exceptions don't leak from that. So, whenever it's the generator (or code > called by it) that raises an exception, that must be kept local to the > generator. > Please review: https://github.com/vitek/cython/commit/73014aaed10b82a3f632d7f86212f86280c55858 I've added __Pyx_Generator_SwapExceptions() method and call it right before resume switch and before return from yield. It swaps generator exception state with thread local. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Recent bugs in generators
Vitja Makarov, 20.04.2011 10:26: 2011/4/18 Stefan Behnel: Vitja Makarov, 18.04.2011 06:38: 2011/4/18 Stefan Behnel: Vitja Makarov, 17.04.2011 17:57: 3. check_yield_in_exception() I added this because I found a failing pyregr test that uses it (testing the @contextmanager decorator). Cython calls __Pyx_ExceptionReset when except block is done, so when yield is there no exception reset is called. I'm not sure how to fix this. I'm not completely sure either. import sys def foo(): """ >>> list(foo()) [, None] """ try: raise ValueError except ValueError: yield sys.exc_info()[0] yield sys.exc_info()[0] # exc_info is lost here I think (!), the difference here is that CPython actually keeps the exception in the generator frame. We don't have a frame, so we have to emulate it using the closure class. I guess we'll have to store away the exception into the closure when we yield while an exception is being handled, and restore it afterwards. Note: this is not the exception that is freshly *being* raised (the "_cur*" fields in the thread state), it's the exception that *was* raised and is now being handled, i.e. the thread state fields without the "_cur", that are reflected by sys.exc_info(). Interesting difference between py2 and py3: def foo(): try: raise ValueError except ValueError: yield raise list(foo()) File "xxx.py", line 7, in list(foo()) File "xxx.py", line 6, in foo raise TypeError: exceptions must be old-style classes or derived from BaseException, not NoneType It seems that exception info is completely lost (tried 2.6, 2.7) and seems to be fixed in python3. Not surprising. The implementation is completely different in Py2 and Py3, both in CPython and in Cython. It's actually much simpler in Cython under Py3, due to better semantics and C-API support. That also implies that there's much less Cython can do wrong in that environment. ;-) Btw exception info temps are already saved and restored between yields. Right, but the exc_info itself is not reset and recovered around the yield. As I said above, generators have their own lifetime frame in CPython, and exceptions don't leak from that. So, whenever it's the generator (or code called by it) that raises an exception, that must be kept local to the generator. Please review: https://github.com/vitek/cython/commit/73014aaed10b82a3f632d7f86212f86280c55858 I've added __Pyx_Generator_SwapExceptions() method and call it right before resume switch and before return from yield. It swaps generator exception state with thread local. Looks good to me. I assume this fixes the problem? Then please push it into mainline. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Recent bugs in generators
2011/4/20 Stefan Behnel : > Vitja Makarov, 20.04.2011 10:26: >> >> 2011/4/18 Stefan Behnel: >>> >>> Vitja Makarov, 18.04.2011 06:38: 2011/4/18 Stefan Behnel: > > Vitja Makarov, 17.04.2011 17:57: >> >> 3. check_yield_in_exception() > > I added this because I found a failing pyregr test that uses it > (testing > the > @contextmanager decorator). > > >> Cython calls __Pyx_ExceptionReset when except block is done, so when >> yield is there no exception reset is called. >> >> I'm not sure how to fix this. > > I'm not completely sure either. > > >> import sys >> >> def foo(): >> """ >> >>> list(foo()) >> [, None] >> """ >> try: >> raise ValueError >> except ValueError: >> yield sys.exc_info()[0] >> yield sys.exc_info()[0] # exc_info is lost here > > I think (!), the difference here is that CPython actually keeps the > exception in the generator frame. We don't have a frame, so we have to > emulate it using the closure class. I guess we'll have to store away > the > exception into the closure when we yield while an exception is being > handled, and restore it afterwards. Note: this is not the exception > that > is > freshly *being* raised (the "_cur*" fields in the thread state), it's > the > exception that *was* raised and is now being handled, i.e. the thread > state > fields without the "_cur", that are reflected by sys.exc_info(). Interesting difference between py2 and py3: def foo(): try: raise ValueError except ValueError: yield raise list(foo()) File "xxx.py", line 7, in list(foo()) File "xxx.py", line 6, in foo raise TypeError: exceptions must be old-style classes or derived from BaseException, not NoneType It seems that exception info is completely lost (tried 2.6, 2.7) and seems to be fixed in python3. >>> >>> Not surprising. The implementation is completely different in Py2 and >>> Py3, >>> both in CPython and in Cython. It's actually much simpler in Cython under >>> Py3, due to better semantics and C-API support. That also implies that >>> there's much less Cython can do wrong in that environment. ;-) >>> >>> Btw exception info temps are already saved and restored between yields. >>> >>> Right, but the exc_info itself is not reset and recovered around the >>> yield. >>> As I said above, generators have their own lifetime frame in CPython, and >>> exceptions don't leak from that. So, whenever it's the generator (or code >>> called by it) that raises an exception, that must be kept local to the >>> generator. >> >> Please review: >> >> https://github.com/vitek/cython/commit/73014aaed10b82a3f632d7f86212f86280c55858 >> >> I've added __Pyx_Generator_SwapExceptions() method and call it right >> before resume switch and before return from yield. It swaps generator >> exception state with thread local. > > Looks good to me. I assume this fixes the problem? Then please push it into > mainline. > old pull request is still there ;) https://github.com/cython/cython/pull/25 Does __Pyx_ExceptionReset() steal references to args, so they should not be decrefed later? -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Recent bugs in generators
Vitja Makarov, 20.04.2011 11:50: 2011/4/20 Stefan Behnel: Vitja Makarov, 20.04.2011 10:26: 2011/4/18 Stefan Behnel: generators have their own lifetime frame in CPython, and exceptions don't leak from that. So, whenever it's the generator (or code called by it) that raises an exception, that must be kept local to the generator. Please review: https://github.com/vitek/cython/commit/73014aaed10b82a3f632d7f86212f86280c55858 I've added __Pyx_Generator_SwapExceptions() method and call it right before resume switch and before return from yield. It swaps generator exception state with thread local. Looks good to me. I assume this fixes the problem? Then please push it into mainline. old pull request is still there ;) https://github.com/cython/cython/pull/25 Does __Pyx_ExceptionReset() steal references to args, so they should not be decrefed later? Hmm, good call. The refcounting looks correct over the two function calls, but it would be nicer if it could be avoided instead. We are really just swapping around pointers here, no refcounting is needed. I think it's worth using a dedicated utility function for this. Oh, and one more thing: what should be done when exiting the generator normally? Would that just raise GeneratorExit anyway, so that we can swallow any original outer exception? I think there might be a problem with Python 3, where the GeneratorExit should be raised in the context of the original exception. Worth testing how CPython behaves here... Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Recent bugs in generators
2011/4/20 Stefan Behnel : > Vitja Makarov, 20.04.2011 11:50: >> >> 2011/4/20 Stefan Behnel: >>> >>> Vitja Makarov, 20.04.2011 10:26: 2011/4/18 Stefan Behnel: > > generators have their own lifetime frame in CPython, and > exceptions don't leak from that. So, whenever it's the generator (or > code > called by it) that raises an exception, that must be kept local to the > generator. Please review: https://github.com/vitek/cython/commit/73014aaed10b82a3f632d7f86212f86280c55858 I've added __Pyx_Generator_SwapExceptions() method and call it right before resume switch and before return from yield. It swaps generator exception state with thread local. >>> >>> Looks good to me. I assume this fixes the problem? Then please push it >>> into >>> mainline. >> >> old pull request is still there ;) >> >> https://github.com/cython/cython/pull/25 >> >> Does __Pyx_ExceptionReset() steal references to args, so they should >> not be decrefed later? > > Hmm, good call. The refcounting looks correct over the two function calls, > but it would be nicer if it could be avoided instead. We are really just > swapping around pointers here, no refcounting is needed. > > I think it's worth using a dedicated utility function for this. > Do you mean new utility call __Pyx_ExceptionSwap()? > Oh, and one more thing: what should be done when exiting the generator > normally? Would that just raise GeneratorExit anyway, so that we can swallow > any original outer exception? I think there might be a problem with Python > 3, where the GeneratorExit should be raised in the context of the original > exception. Worth testing how CPython behaves here... > Right! It's better to wrap call to generator: ExceptionSwap(); generator_body(); ExceptionSwap(); Ok, I'll take a look. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Recent bugs in generators
Vitja Makarov, 20.04.2011 12:51: 2011/4/20 Stefan Behnel: Vitja Makarov, 20.04.2011 11:50: 2011/4/20 Stefan Behnel: Vitja Makarov, 20.04.2011 10:26: 2011/4/18 Stefan Behnel: generators have their own lifetime frame in CPython, and exceptions don't leak from that. So, whenever it's the generator (or code called by it) that raises an exception, that must be kept local to the generator. Please review: https://github.com/vitek/cython/commit/73014aaed10b82a3f632d7f86212f86280c55858 I've added __Pyx_Generator_SwapExceptions() method and call it right before resume switch and before return from yield. It swaps generator exception state with thread local. Looks good to me. I assume this fixes the problem? Then please push it into mainline. old pull request is still there ;) https://github.com/cython/cython/pull/25 Does __Pyx_ExceptionReset() steal references to args, so they should not be decrefed later? Hmm, good call. The refcounting looks correct over the two function calls, but it would be nicer if it could be avoided instead. We are really just swapping around pointers here, no refcounting is needed. I think it's worth using a dedicated utility function for this. Do you mean new utility call __Pyx_ExceptionSwap()? Yes. I think it doesn't even have to be specific to the generator code. Just pass in "&gen->exc_type" etc. Oh, and one more thing: what should be done when exiting the generator normally? Would that just raise GeneratorExit anyway, so that we can swallow any original outer exception? I think there might be a problem with Python 3, where the GeneratorExit should be raised in the context of the original exception. Worth testing how CPython behaves here... Right! It's better to wrap call to generator: ExceptionSwap(); generator_body(); ExceptionSwap(); Good idea. Ok, I'll take a look. Cool. Thanks! Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Recent bugs in generators
2011/4/20 Stefan Behnel : > Vitja Makarov, 20.04.2011 12:51: >> >> 2011/4/20 Stefan Behnel: >>> >>> Vitja Makarov, 20.04.2011 11:50: 2011/4/20 Stefan Behnel: > > Vitja Makarov, 20.04.2011 10:26: >> >> 2011/4/18 Stefan Behnel: >>> >>> generators have their own lifetime frame in CPython, and >>> exceptions don't leak from that. So, whenever it's the generator (or >>> code >>> called by it) that raises an exception, that must be kept local to >>> the >>> generator. >> >> Please review: >> >> >> >> https://github.com/vitek/cython/commit/73014aaed10b82a3f632d7f86212f86280c55858 >> >> I've added __Pyx_Generator_SwapExceptions() method and call it right >> before resume switch and before return from yield. It swaps generator >> exception state with thread local. > > Looks good to me. I assume this fixes the problem? Then please push it > into > mainline. old pull request is still there ;) https://github.com/cython/cython/pull/25 Does __Pyx_ExceptionReset() steal references to args, so they should not be decrefed later? >>> >>> Hmm, good call. The refcounting looks correct over the two function >>> calls, >>> but it would be nicer if it could be avoided instead. We are really just >>> swapping around pointers here, no refcounting is needed. >>> >>> I think it's worth using a dedicated utility function for this. >>> >> >> Do you mean new utility call __Pyx_ExceptionSwap()? > > Yes. I think it doesn't even have to be specific to the generator code. Just > pass in "&gen->exc_type" etc. > > >>> Oh, and one more thing: what should be done when exiting the generator >>> normally? Would that just raise GeneratorExit anyway, so that we can >>> swallow >>> any original outer exception? I think there might be a problem with >>> Python >>> 3, where the GeneratorExit should be raised in the context of the >>> original >>> exception. Worth testing how CPython behaves here... >>> >> >> >> Right! It's better to wrap call to generator: >> >> ExceptionSwap(); >> generator_body(); >> ExceptionSwap(); > > Good idea. > > >> Ok, I'll take a look. > > Cool. Thanks! > https://github.com/vitek/cython/compare/73014aaed1...01286645d0 Another one try ;) -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] libcpp.string operators
On 19 April 2011 21:22, Brent Pedersen wrote:
> On Tue, Apr 19, 2011 at 6:08 PM, Brent Pedersen wrote:
>> On Tue, Apr 19, 2011 at 2:45 PM, Brent Pedersen wrote:
>>> hi, i have been using a stub for the c++ in a lot of my work.
>>> i decided to have a go at doing a proper string.pxd, pasted here:
>>>
>>> https://gist.github.com/929604
>>>
>>> other than the operators, it's mostly implemented with tests. but when
>>> i try the operators
>>> with this test:
>>>
>>> def test_equal_operator(char *a, char *b):
>>> """
>>> >>> test_equal_operator("asdf", "asdf")
>>> True
>>> """
>>> cdef string s = string(a)
>>> cdef string t = string(b)
>>> cdef bint same = t == s
>>> return same
>>>
>>> and this declaration in the pxd:
>>>
>>> bint operator==(string&, string&)
>>
>>
>> it seems:
>>
>> bint operator==(string&)
>>
>> is the correct syntax. i had copied the stuff from vector.pxd
>>
>>>
>>> i get the error below. any ideas what i'm doing wrong?
>>> thanks,
>>> -brent
>>>
>>>
>>>
>>>
>>>
>>> === Got errors: ===
>>> 152:23: Invalid types for '==' (string, string)
>>>
>>>
>>> ==
>>> ERROR: runTest (__main__.CythonRunTestCase)
>>> compiling (cpp) and running cpp_stl_string
>>> --
>>> Traceback (most recent call last):
>>> File "runtests.py", line 569, in run
>>> self.runCompileTest()
>>> File "runtests.py", line 400, in runCompileTest
>>> self.test_directory, self.expect_errors, self.annotate)
>>> File "runtests.py", line 546, in compile
>>> self.assertEquals(None, unexpected_error)
>>> AssertionError: None != u"152:23: Invalid types for '==' (string, string)"
>>>
>>
>
> i updated the gist with the operators, didn't do iterators.
> https://gist.github.com/929604
>
Looks pretty good. Could you fork the devel repo, add the pxd and the
test at appropriate places and make a pull request? This is just in
order to give you credits for your work.
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] libcpp.string operators
Lisandro Dalcin, 20.04.2011 16:09:
On 19 April 2011 21:22, Brent Pedersen wrote:
On Tue, Apr 19, 2011 at 6:08 PM, Brent Pedersen wrote:
On Tue, Apr 19, 2011 at 2:45 PM, Brent Pedersen wrote:
hi, i have been using a stub for the c++ in a lot of my work.
i decided to have a go at doing a proper string.pxd, pasted here:
https://gist.github.com/929604
other than the operators, it's mostly implemented with tests. but when
i try the operators
with this test:
def test_equal_operator(char *a, char *b):
"""
>>> test_equal_operator("asdf", "asdf")
True
"""
cdef string s = string(a)
cdef string t = string(b)
cdef bint same = t == s
return same
and this declaration in the pxd:
bint operator==(string&, string&)
it seems:
bint operator==(string&)
is the correct syntax. i had copied the stuff from vector.pxd
i get the error below. any ideas what i'm doing wrong?
thanks,
-brent
=== Got errors: ===
152:23: Invalid types for '==' (string, string)
==
ERROR: runTest (__main__.CythonRunTestCase)
compiling (cpp) and running cpp_stl_string
--
Traceback (most recent call last):
File "runtests.py", line 569, in run
self.runCompileTest()
File "runtests.py", line 400, in runCompileTest
self.test_directory, self.expect_errors, self.annotate)
File "runtests.py", line 546, in compile
self.assertEquals(None, unexpected_error)
AssertionError: None != u"152:23: Invalid types for '==' (string, string)"
i updated the gist with the operators, didn't do iterators.
https://gist.github.com/929604
Looks pretty good. Could you fork the devel repo, add the pxd and the
test at appropriate places and make a pull request? This is just in
order to give you credits for your work.
Looks like this wasn't tested with Python 3, there are 16 failing tests
more now.
https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-py3k-cpp/952/
Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] libcpp.string operators
On Wed, Apr 20, 2011 at 9:58 AM, Stefan Behnel wrote:
> Lisandro Dalcin, 20.04.2011 16:09:
>>
>> On 19 April 2011 21:22, Brent Pedersen wrote:
>>>
>>> On Tue, Apr 19, 2011 at 6:08 PM, Brent Pedersen
>>> wrote:
On Tue, Apr 19, 2011 at 2:45 PM, Brent Pedersen
wrote:
>
> hi, i have been using a stub for the c++ in a lot of my work.
> i decided to have a go at doing a proper string.pxd, pasted here:
>
> https://gist.github.com/929604
>
> other than the operators, it's mostly implemented with tests. but when
> i try the operators
> with this test:
>
> def test_equal_operator(char *a, char *b):
> """
> >>> test_equal_operator("asdf", "asdf")
> True
> """
> cdef string s = string(a)
> cdef string t = string(b)
> cdef bint same = t == s
> return same
>
> and this declaration in the pxd:
>
> bint operator==(string&, string&)
it seems:
bint operator==(string&)
is the correct syntax. i had copied the stuff from vector.pxd
>
> i get the error below. any ideas what i'm doing wrong?
> thanks,
> -brent
>
>
>
>
>
> === Got errors: ===
> 152:23: Invalid types for '==' (string, string)
>
>
> ==
> ERROR: runTest (__main__.CythonRunTestCase)
> compiling (cpp) and running cpp_stl_string
> --
> Traceback (most recent call last):
> File "runtests.py", line 569, in run
> self.runCompileTest()
> File "runtests.py", line 400, in runCompileTest
> self.test_directory, self.expect_errors, self.annotate)
> File "runtests.py", line 546, in compile
> self.assertEquals(None, unexpected_error)
> AssertionError: None != u"152:23: Invalid types for '==' (string,
> string)"
>
>>>
>>> i updated the gist with the operators, didn't do iterators.
>>> https://gist.github.com/929604
>>>
>>
>> Looks pretty good. Could you fork the devel repo, add the pxd and the
>> test at appropriate places and make a pull request? This is just in
>> order to give you credits for your work.
>
> Looks like this wasn't tested with Python 3, there are 16 failing tests more
> now.
>
> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-py3k-cpp/952/
>
> Stefan
> ___
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
is the solution to prefix the string literals with 'b'? e.g.
>>> test_indexing(b"asdf")
or something else? that passes in python 2.6, 2.7 and 3.2 for me.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] libcpp.string operators
Stefan Behnel, 20.04.2011 17:58: Lisandro Dalcin, 20.04.2011 16:09: On 19 April 2011 21:22, Brent Pedersen wrote: hi, i have been using a stub for the c++ in a lot of my work. i decided to have a go at doing a proper string.pxd, pasted here: https://gist.github.com/929604 Looks pretty good. Could you fork the devel repo, add the pxd and the test at appropriate places and make a pull request? This is just in order to give you credits for your work. Looks like this wasn't tested with Python 3, there are 16 failing tests more now. https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-py3k-cpp/952/ I fixed it up. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] libcpp.string operators
Brent Pedersen, 20.04.2011 18:29:
On Wed, Apr 20, 2011 at 9:58 AM, Stefan Behnel wrote:
Lisandro Dalcin, 20.04.2011 16:09:
On Tue, Apr 19, 2011 at 2:45 PM, Brent Pedersen wrote:
hi, i have been using a stub for the c++in a lot of my work.
i decided to have a go at doing a proper string.pxd, pasted here:
https://gist.github.com/929604
Looks pretty good. Could you fork the devel repo, add the pxd and the
test at appropriate places and make a pull request? This is just in
order to give you credits for your work.
Looks like this wasn't tested with Python 3, there are 16 failing tests more
now.
https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-py3k-cpp/952/
is the solution to prefix the string literals with 'b'? e.g.
>>> test_indexing(b"asdf")
or something else? that passes in python 2.6, 2.7 and 3.2 for me.
... but not in Py2.3-2.5. No, you need to either use byte strings created
in Cython code, or use a hack that works on both Py2 and Py3, such as
'xyz'.encode('ASCII').
Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] libcpp.string operators
On Wed, Apr 20, 2011 at 10:34 AM, Stefan Behnel wrote:
> Brent Pedersen, 20.04.2011 18:29:
>>
>> On Wed, Apr 20, 2011 at 9:58 AM, Stefan Behnel wrote:
>>>
>>> Lisandro Dalcin, 20.04.2011 16:09:
>>
>> On Tue, Apr 19, 2011 at 2:45 PM, Brent Pedersen wrote:
>>>
>>> hi, i have been using a stub for the c++ in a lot of my
>>> work.
>>> i decided to have a go at doing a proper string.pxd, pasted here:
>>>
>>> https://gist.github.com/929604
>>>
Looks pretty good. Could you fork the devel repo, add the pxd and the
test at appropriate places and make a pull request? This is just in
order to give you credits for your work.
>>>
>>> Looks like this wasn't tested with Python 3, there are 16 failing tests
>>> more
>>> now.
>>>
>>>
>>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-py3k-cpp/952/
>>>
>> is the solution to prefix the string literals with 'b'? e.g.
>>
>> >>> test_indexing(b"asdf")
>>
>> or something else? that passes in python 2.6, 2.7 and 3.2 for me.
>
> ... but not in Py2.3-2.5. No, you need to either use byte strings created in
> Cython code, or use a hack that works on both Py2 and Py3, such as
> 'xyz'.encode('ASCII').
>
> Stefan
> ___
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
good to know. thanks.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] On cdef extern from syntax
On Wed, Apr 20, 2011 at 11:08 AM, Fabrizio Milo aka misto
wrote:
> Hi,
>
> I was wondering if has been ever discussed to implement the cython
> cdef extern from syntax as a with statement:
>
> with cython.header_importer("") as cy:
> cy.ctypedef(" unsigned int uint8 ")
> cy.cfunc( " void * myfunc() )")
>
> or also
>
> with cython.header_importer("") as cy:
> cy("""
> ctypdef ...
>
> """)
>
> Maybe there is already something like that ?
I don't think the with statement really makes sense here, as it is a
list of global declarations, and the with statement is all about
making something local to a block.
- Robert
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Build module script
Now we have cythonrun build script, may be it's time to create script for easy module building? -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
