Arik Funke created ARROW-6416:
---------------------------------

             Summary: [Python] Confusing API & documentation regarding 
chunksizes
                 Key: ARROW-6416
                 URL: https://issues.apache.org/jira/browse/ARROW-6416
             Project: Apache Arrow
          Issue Type: Bug
            Reporter: Arik Funke


The python API and documentation regarding chunksizes is confusing in my 
opinion:

Example:

[https://arrow.apache.org/docs/python/generated/pyarrow.RecordBatchFileWriter.html#pyarrow.RecordBatchFileWriter.write_table]
{color:#0000ff}def{color} 
{color:#795e26}write_table{color}{color:#000000}({color}{color:#001080}self{color}{color:#000000},
 Table {color}{color:#001080}table{color}{color:#000000}, 
{color}{color:#001080}chunksize{color}{color:#000000}={color}{color:#0000ff}None{color}{color:#000000}):{color}
{color:#a31515}"""{color}
{color:#a31515} Write RecordBatch to stream{color}

{color:#a31515} Parameters{color}
{color:#a31515} ----------{color}
{color:#a31515} batch : RecordBatch{color}
 
This suggests, the file will be written with a fixed chunk size when in fact 
the {{chunksize}} parameter is an upper bound on the size of the chunks to be 
written.

In my opinion this parameter should be renamed {{max_chunksize}} to avoid 
confusion and reflect its true purpose.

This would also improve naming consistency in the code base, since in the C++ 
implementation, this parameter is already named {{max_chunksize}} in 
{{cpp/source/arrow/ipc/writer.cc}}:
{color:#000000}Status 
{color}{color:#267f99}RecordBatchWriter{color}{color:#000000}::{color}{color:#795e26}WriteTable{color}{color:#000000}({color}{color:#0000ff}const{color}{color:#000000}
 Table{color}{color:#000000}&{color}{color:#001080} 
table{color}{color:#000000}, {color}{color:#0000ff}int64_t{color} 
{color:#001080}max_chunksize{color}{color:#000000}) {{color}
Similarly, the parameter should be renamed in {{pyarrow.Table.to_batches(self, 
chunksize=None)}}.

 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Reply via email to