Again, while trying it out this branch, I noticed some oddities. But now they are certainly not related to the code in this PR, as they also hold for non-large ListType.

When creating an array from offsets and values in python, there is no validation of the offsets that it starts with 0 and ends with the length of the array (but is that required? the docs seem to indicate that: https://github.com/apache/arrow/blob/master/docs/source/format/Layout.rst#list-type ("The first value in the offsets array is 0, and the last element is the length of the values array.").
The array you get "seems" ok (the repr), but on conversion to python or flattened arrays, things go wrong:

In [61]: a = pa.ListArray.from_arrays([1,3,10], np.arange(5)) 

In [62]: a
Out[62]: 
<pyarrow.lib.ListArray object at 0x7fdd9c468678>
[
  [
    1,
    2
  ],
  [
    3,
    4
  ]
]

In [63]: a.flatten()
Out[63]: 
<pyarrow.lib.Int64Array object at 0x7fdd9cbfe9e8>
[
  0,   # <--- includes the 0
  1,
  2,
  3,
  4
]

In [64]: a.to_pylist()
Out[64]: [[1, 2], [3, 4, 1121, 1, 64, 93969433636432, 13]]  # <--includes more elements as garbage

I understand that in C++ the main constructors are not safe, and as the caller you need to ensure that the data is correct or call a safe (slower) constructor. But do we want to use the unsafe / fast constructors without validation in Python as default as well?

Ah, I see that in Python a validation function is exposed, and this actually raises:

In [65]: a.validate()                                                                                                                                                                                              
---------------------------------------------------------------------------
ArrowInvalid                              Traceback (most recent call last)
<ipython-input-65-b377de7e0b22> in <module>
----> 1 a.validate()

~/scipy/repos/arrow/python/pyarrow/array.pxi in pyarrow.lib.Array.validate()

~/scipy/repos/arrow/python/pyarrow/error.pxi in pyarrow.lib.check_status()

ArrowInvalid: Final offset invariant not equal to values length: 10!=5

Do we want to call that by default in the creation method?
A quick search seems to indicate that pa.Array.from_buffers does this, but other from_arrays method don't seem to explicitly do this. But eg in DictionaryArray.from_arrays, if you pass values that is too short for the max of the indices, you do get an error.

On the C++ side indeed, calling validation for each constructor would be expensive. We can adopt a different strategy for Python. Can you open a JIRA about that?

Opened https://issues.apache.org/jira/browse/ARROW-6132

@wesm Do you want to take a look here or can I merge as-is? (assuming the R AppVeyor failure isn't related)

Rebased.

Codecov Report

Merging #4979 into master will increase coverage by 1.6%.
The diff coverage is 87.4%.

@@            Coverage Diff             @@
##           master    #4979      +/-   ##
==========================================
+ Coverage   87.57%   89.17%    +1.6%     
==========================================
  Files        1005      727     -278     
  Lines      143560   103008   -40552     
  Branches     1418        0    -1418     
==========================================
- Hits       125720    91862   -33858     
+ Misses      17478    11146    -6332     
+ Partials      362        0     -362

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 42f4f34...4266ea2. Read the comment docs.

Taking a look