yohplala

> > I am sorry, I don't have a clear picture of the content of _metadata vs _common_metadata. > > Please, what do we gain to keep _common_metadata but not...

> in both numerical and lexical sorting. My proposal would be: Fastparquet already has a "naming convention" that I find ok. I would to check if filename is according this...

> > Should we add a mechanism to check this file on append and update it if different than original and if row group is successfully written? > > >...

> Do you think we could define a convention here about its value? Currently, - if reading a single parquet file, `pf.fn` is the parquet file name `test.parquet` - if...

> Yes, I'd be happy with that convention. I think it's more typical to use the _first_ found parquet file rather than the last. So far, I was thinking that...

> > in both numerical and lexical sorting. > > My proposal would be: > > Fastparquet already has a "naming convention" that I find ok. I would to check...

> If it has changed as a consequence of append operations, then you are right that the last file should be the most up to date. Ok this is the...

@martindurant , I think here is a sum up of all our discussions so far: - [ ] adjust fastparquet behavior when instantiating a `ParquetFile`: - fix '5/' : when...

> The only thing we don't consider in all this is a ParquetFile made from a list of paths. We could simply refuse to append in that case. I am...

About parameter name to be set to write or not `_metadata` file: currently, in `write_multi`, and in all "new" `ParquetFile` methods I created to make it "more mutable" (create row...