Re: Bug: Python SRC exec tuple fails [7.9.3f (release_7.9.3f-17-g7524ef <at> MY-PATH/)]

["Andreas Röhler" <andreas.roehler@easy-emacs.de>]

Am 09.05.2013 16:33, schrieb Roland Donat:
> Andreas Röhler <andreas.roehler <at> easy-emacs.de> writes:
>
>>
>> Am 08.05.2013 22:50, schrieb Roland Donat:
>>>>> Yes, you're right Andreas. It "fails" to show the accented characters
> if
>>> you
>>>>> try to print the entire tuple.
>>>>> It fails too if you evaluate a[0][0] in your interpreter. You should
> see
>>> :
>>>>>>>> a[0][0]
>>>>> '\xc3\xa9'
>>>>> But print a[0][0] gives the expected answer 'é'
>>>>>
>>>>> So, based on your successful experience consisting in returning a[0]
> [0]
>>> in
>>>>> the orgmode source block, we can assume that org-babel use the python
>>> print
>>>>> function to display results in org buffer, aren't we?
>>>>>
>>>>> Another strange behaviour, when you evaluate the src_block test given
> in
>>>>> example, you get :
>>>>> | \303\251 | a        |
>>>>> | a        | \303\240 |
>>>>>
>>>>> Whereas I was expecting to get the same code than in the python
>>> interpreter,
>>>>> that is :
>>>>> | \xc3\xa9 | a          |
>>>>> | a        | '\xc3\xa0' |
>>>>>
>>>>> In addition, when I try to save my buffer, Emacs doesn't recognize the
>>>>> encoding of characters \303\251 and \303\240 and asks me to choose an
>>>>> encoding. Then, I enter utf-8 and nothing happens BUT when I quit and
>>> reopen
>>>>> my file : the characters are printed correctly.... Too strange for
>>> me....
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Roland.
>>>>
>>>> so what about that:
>>>>
>>>> a = ( ( "é", "a" ), ( "a", "à" ) )
>>>> for i, j in a:
>>>>        print i, j
>>>>
>>>> BTW previous post was sent prematurely..
>>>>
>>>> Andreas
>>>>
>>>>
>>>
>>> Yep, using a couple of for loops will work but the result won't return
> as a
>>> table which is a requirement for me.
>>>
>>> To precise the context a littre more, I have basically 2 source blocks :
>>> 1) the famous python block which must return a table
>>> 2) a R block used to post-process the previous table
>>>
>>> Well, thanks for your help.
>>> I think I spent too much time on this so I'm thinking about changing my
>>> approach. For example, put the result of the first step into a file and
> then
>>> process the file in step 2.
>>>
>>> Best regards,
>>>
>>> Roland.
>>
>> Just playing a little bit with your example, what about this:
>>
>> #+begin_src python :results output :preamble # -*- coding: utf-8 -*-
>> a = ( ( "é", "a" ), ( "a", "à" ) )
>> for i, j in a:
>>       print("|%s | %s|" % (i, j))
>> #+end_src
>>
>>
> Yes Andreas! It works just fine for the python block. But when the python
> result arrives as input of my R post
> processing code,

[ ... ]

The bug so far affected the display only, not the data.
Feeding R with the result returned from your original form should work.

Best,

Andreas