Re: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks

[Rick Frankel <rick@rickster.com>]

On 2013-07-23 08:25, Sebastien Vauban wrote:
> Torsten Wagner wrote:
> I want to summarize the problem I found, using tables as input to 
> source
> code blocks.
> This observation was shared with Rick and I would be glad to help 
> fixing
> that.
> 
> Within the attached file one can see a typical example.
> 
> It all comes down to a differently interpretation of tables  with 
> respect
> to horizontal line.
> 
> #+TBLNAME: with-hline
> | A | B | C |
> |---+---+---|
> | 1 | 2 | 3 |
> | X | Y | Z |
> 
> and
> 
> #+TBLNAME: without-hline
> | A | B | C |
> | 1 | 2 | 3 |
> | X | Y | Z |
> 
> will give different results being called by
> 
> #+name: python-element
> #+begin_src python :var table=with-hline :exports results
> return table[1]
> #+end_src
> 
> or
> 
> #+CALL: python-echo(with-hline)
> 
> Please see the attached file for details.
> 
> From what I was able to observe:
> 
> 1. Calling a table with hline, the result of the source code block miss 
> the
> first row. Indexing is possible only for the second and third row (in 
> the
> given example)
> 
> 2. Having no hline, the first row is available, indexing of the first 
> row
> works too.
> 
> Using a Call construct:
> 1. for a table without hline, indexing works but it does not work for a
> table with hline.
> 2. Interestingly, using the CALL functions, the type of both tables in
> python is list for the entire table, however, indexing a table with 
> hlines,
> the type becomes NoneType whereas for a table without hline it is still 
> of
> type list.
> 
> Hope that can somehow help to get an idea what is going on.
> 
> I think the reason comes from the fact that different default header 
> args
> exist depending on the way the code is eval'ed.
> 
> See the contents of the following vars:
> 
> - `org-babel-default-header-args' for source blocks
> - `org-babel-default-inline-header-args' for inline source blocks
> - `org-babel-default-lob-header-args' for `#+call' lines
> 
> So, you clearly needs to add explicit values for some of your header 
> arguments
> in your call line.

I don't think this is the cause of the problem. The problem seems to be
universal in the babel handling of column names (`:colnames') in input
and output tables and it's application, as well as different handling
of `call' lines with and without explicit input arguments (see [1] and
[2].) Regardless, the handling of tables with and without a header
separated by an hline are definitely affected by the values of the
`:colnames' and `:hlines' header arguments, but the difference between
the results from the original source block and the call lines with and
without an explicit argument are still inconsistent. Just to cover some:

#+BEGIN_ORG
#+TBLNAME: with-hline
| A | B | C |
|---+---+---|
| 1 | 2 | 3 |
| X | Y | Z |

#+name: python-echo
#+header: :colnames '()
#+begin_src python :var table=with-hline
return table
#+end_src

#+RESULTS: python-echo
| 1 | 2 | 3 |
| X | Y | Z |

#+header: :colnames no
#+begin_src python :var table=with-hline
return table
#+end_src

#+RESULTS:
| A | B | C |
| 1 | 2 | 3 |
| X | Y | Z |

#+header: :colnames yes
#+begin_src python :var table=with-hline
return table
#+end_src

#+RESULTS:
| A | B | C |
|---+---+---|
| 1 | 2 | 3 |
| X | Y | Z |

#+call: python-echo()

#+RESULTS:
| 1 | 2 | 3 |
| X | Y | Z |

#+call: python-echo() :colnames yes

#+RESULTS:
| 1 | 2 | 3 |
|---+---+---|
| X | Y | Z |

#+call: python-echo[:colnames yes]()

#+RESULTS:
| A | B | C |
|---+---+---|
| 1 | 2 | 3 |
| X | Y | Z |

#+call: python-echo(table=with-hline)

#+RESULTS:
| A | B | C |
|---+---+---|
| 1 | 2 | 3 |
| X | Y | Z |


#+call: python-echo(table=with-hline) :colnames yes

#+RESULTS:
| A | B | C |
|---+---+---|
| 1 | 2 | 3 |
| X | Y | Z |

#+call: python-echo[:colnames yes](table=with-hline) :colnames yes

#+RESULTS:
| A | B | C |
|---+---+---|
| A | B | C |
|---+---+---|
| 1 | 2 | 3 |
| X | Y | Z |

#+END_ORG

[1] http://article.gmane.org/gmane.emacs.orgmode/74897
[2] http://article.gmane.org/gmane.emacs.orgmode/74452