# \[ANN\] CSV.jl 0.9 Release

**URL:** <https://discourse.julialang.org/t/ann-csv-jl-0-9-release/67844>\
**Category:** Data\
**Created:** [September 8, 2021, 4:37am UTC](https://discourse.julialang.org/t/ann-csv-jl-0-9-release/67844 "2021-09-08T04:37:36Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![quinnj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/quinnj/32/11_2.png) [@quinnj](https://discourse.julialang.org/u/quinnj)\
**Post date:** [September 8, 2021, 4:37am UTC](https://discourse.julialang.org/t/ann-csv-jl-0-9-release/67844/1 "2021-09-08T04:37:36Z")

</div>

Hello all,

We’re pleased to present the [0.9 release](https://github.com/JuliaData/CSV.jl/releases/tag/v0.9.0) of [CSV.jl](https://github.com/JuliaData/CSV.jl).

Highlights include:

- [Big internals refactoring](https://github.com/JuliaData/CSV.jl/commit/bfd415d0af4c7c1842ecc5b54f1e4a18b125a264) to simplify code, make maintenance/future feature work easier, and make current features a little more robust in terms of multithreading/performance
- Support for two new custom string types builtin to parsing: [InlineStrings](https://github.com/JuliaData/WeakRefStrings.jl/blob/2571596c7f2176f2c461e83aaf71df057f6112d5/src/inlinestrings.jl#L4) and [PosLenStrings](https://github.com/JuliaData/WeakRefStrings.jl/blob/2571596c7f2176f2c461e83aaf71df057f6112d5/src/poslenstrings.jl#L6). InlineStrings are a fixed-width string type defined as a `primitive type` which allows for inline storage in `Vector`s and various processing efficiencies from that representation (but which make end up taking up more space when a column has higher variance in the length of strings). PosLenStrings are a new “lazy string” representation where a reference to the original csv input is kept and a PosLenString just points to the range of bytes in the source. These will allow more flexibility depending on use-case/workload to avoid excessive allocations that can result when using regular `String`s on very large files
- Cleanup, review, and simplification of [keyword arguments](https://github.com/JuliaData/CSV.jl/commit/0eaacb4c4d5787a5186dac8edf523ee9052db27f) supported by `CSV.File`/`CSV.Rows`
- [Automatic support for reading gzipped inputs](https://github.com/JuliaData/CSV.jl/commit/5144950ef3743c302fb12a27806767209752c66a), with the ability for decompression to be done to a temporary file (the default) or in memory (by passing `buffer_in_memory=true`), as well as support for writing gzip compressed outputs in `CSV.write` by passing `compress=true`
- [Big overhaul](https://github.com/JuliaData/CSV.jl/commit/17bffa1a5e2bc570e913d1f0bac98e65e3aeb1e4) of the [CSV.jl docs](https://csv.juliadata.org/dev/), including a massively updated “intro” section that walks through all the various APIs provided by the package (turns out people have a hard time knowing about really useful things when they aren’t well documented!); big thanks to all those who contributed feedback (and code) to help improve overall documentation
- New functionality to pass a `Vector` of inputs (be they file names, IO objects, byte vectors, etc.) to `CSV.File` and they’ll all be vertically concatenated and returned as a single `CSV.File` object (currently has strict requirements on matching schemas from all inputs, but this will be relaxed in the future)

This _ **shouldn’t** _ be a breaking release at all, but several deprecations were introduced in the keyword argument cleanup. There were also some additional restrictions/type constraints placed on various arguments, so if you do notice things not working that worked before, please [open an issue](https://github.com/JuliaData/CSV.jl/issues/new) and we can figure out how to fix/support.

## Why isn’t this the 1.0 release??

Good question: we’re really close. We wanted to provide one more release with the number of deprecations to allow a transition period. With the big internals refactoring, new string support, and overall amount of work that went into this release, we also just want to let bugs shake out a bit, iron out the wrinkles, and then put out a more polished 1.0 release in the very near future. It’s currently only being planned as a breaking release by removing the keyword argument deprecations, baring any unexpected issues.

Thanks again to all those willing to provide feedback, file issues, or just express appreciation at the [repo](https://github.com/JuliaData/CSV.jl) or [#data slack channel](https://julialang.slack.com/messages/data/). We look forward to hearing from you!

-Jacob Quinn & JuliaData maintainers

---

<div class="post-metadata">

**Author:** ![quinnj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/quinnj/32/11_2.png) [@quinnj](https://discourse.julialang.org/u/quinnj)\
**Post date:** [September 8, 2021, 5:26am UTC](https://discourse.julialang.org/t/ann-csv-jl-0-9-release/67844/2 "2021-09-08T05:26:37Z")

</div>

[Note there was briefly an issue with the newest docs deploying to [Home · CSV.jl](http://csv.juliadata.org/stable), so if you went there and the docs didn’t look updated, you were right! All should be fixed now]

---

<div class="post-metadata">

**Author:** ![metab0t](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/metab0t/32/15551_2.png) [@metab0t](https://discourse.julialang.org/u/metab0t)\
**Post date:** [September 8, 2021, 7:20am UTC](https://discourse.julialang.org/t/ann-csv-jl-0-9-release/67844/3 "2021-09-08T07:20:54Z")

</div>

@quinnj  
As a side note, a new `SQLite.jl` release should be made to support `WeakRefStrings.jl` version 1.0, so it won’t block update of `CSV.jl`.

---

<div class="post-metadata">

**Author:** ![sijo](https://avatars.discourse-cdn.com/v4/letter/s/da6949/32.png) [@sijo](https://discourse.julialang.org/u/sijo)\
**Post date:** [September 8, 2021, 7:50am UTC](https://discourse.julialang.org/t/ann-csv-jl-0-9-release/67844/4 "2021-09-08T07:50:29Z")

</div>

Thanks for another great release!

> [@quinnj](#):
>
> Cleanup, review, and simplification of [keyword arguments](https://github.com/JuliaData/CSV.jl/commit/0eaacb4c4d5787a5186dac8edf523ee9052db27f)

Since you’re in the business of polishing the keywords 😄 : `downcast` seems like a weird name to me (I think it normally means something else, e.g. converting from `Integer` to `Int32` rather than `Int64` to `Int32`) and the name doesn’t really convey the point (it emphasizes “more specialized” type, rather than “smaller”). Maybe `shrinktypes` or just `shrink`?

---

<div class="post-metadata">

**Author:** ![Storopoli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/storopoli/32/209278_2.png) [@Storopoli](https://discourse.julialang.org/u/Storopoli)\
**Post date:** [September 8, 2021, 2:30pm UTC](https://discourse.julialang.org/t/ann-csv-jl-0-9-release/67844/5 "2021-09-08T14:30:20Z")

</div>

> [@quinnj](#):
>
> New functionality to pass a `Vector` of inputs (be they file names, IO objects, byte vectors, etc.) to `CSV.File` and they’ll all be vertically concatenated and returned as a single `CSV.File` object (currently has strict requirements on matching schemas from all inputs, but this will be relaxed in the future)

Is this multithreaded or singlethreaded?

EDIT: never mind. I’ve found [here](https://github.com/JuliaData/CSV.jl/blob/main/src/file.jl#L65-L67):

> When a `Vector` of inputs is provided, the column names and types of each separate file/input must match to be vertically concatenated. Separate threads will  
> be used to parse each input, which will each parse their input using just the single thread. The results of all threads are then vertically concatenated using  
> `ChainedVector`s to lazily concatenate each thread’s columns.