> These are not my recommendations to use. These are only my recommendations
> for deeper research if we are about to roll something on our own. It sounds
> unlikely that such a fundamental need is not addressed in Python ecosystem.
Agreed, I was already aware of all the options you provided. Ho
Thanks for starting this discussion! I think the defensive programming
approach is useful to maintain assumptions, especially in some
public-facing APIs. Here is an example I recently encountered [1]; we
currently disallow using the `add_files` API for parquet files with
field IDs. However, I'm not
Hi Andre,
My Python skills aren't up to date, so I will abstain from recommending a
particular solution.
Writing a precondition module sounds like a fun task, but perhaps we could
research alternatives first.
For example quick google search brought me to
https://pypi.org/project/preconditions/
htt
Thank you Piotr Findeisen and Sung Yun, for your insights.
I did a quick search and didn’t find anything more "pythonic." We could just
use an if statement with raise, but I have some mixed feelings about that.
Maybe we could create a precondition module with a function or a decorator.
What do
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
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