I’d like to offer a perspective on compatibility. If the design is robust
and reasonable, it is certainly welcomed. However, if the design falls
short, it becomes a compromise—not just for Iceberg users, but for the
entire ecosystem.
I look forward to hearing your thoughts on this.
Yufei
On Fr
Hi André,
Thank you for starting off this discussion! This is a fun topic, so I’m
keen on seeing what the rest of the folks in the PyIceberg community think
as well :)
I’m of the opinion that ‘assert’ should only be used within test suites,
because setting the optimize flag (-O) in the Python int
Thanks Christian. Nice write-up! Authentication is essential to a
production env. It's great to document it well given a lot of people don't
necessarily have enough OAthen2 knowledge. Looking forward to the doc PRs
and other client side changes.
Yufei
On Wed, Sep 18, 2024 at 8:31 AM Dmitri Bourl
Hi Andre,
I am not very familiar with PyIceberg, but i am always for ensuring that
assumptions in our code are validated.
I am not quite sure that assert is the way to go though.
In Java, one typically does not use `assert`, which can be enabled or
disabled.
checkState / checkArgument are preferr
I'm fine both ways, with or without release.
I am a strong believer of low-ceremony and automated releases. Maybe we
could automate at least the core part of the release (shipping binaries),
and then we don't need to think so much about when (not) to release,
because it would be cheap to redo if ne
