Hi everyone,

I’d like to open a discussion on the naming scheme for configuration
parameters across different languages.

While working on the LocationProvider implementation in PyIceberg (#1452
<https://github.com/apache/iceberg-python/pull/1452>), we encountered a
challenge with naming configuration parameters for custom implementations.
In the Java library, the parameter `write.location-provider.impl`
<https://github.com/apache/iceberg/blob/be6e9daf8901cdee63197e77fcf95624bb694f39/core/src/main/java/org/apache/iceberg/TableProperties.java#L257>
is used to configure a custom LocationProvider implementation. However, for
cross-language compatibility, we couldn’t reuse this parameter directly.
Configuration parameters defined in one language are not automatically
compatible with others.

To address this in PyIceberg, we chose to use
`write.py-location-provider.impl` as the parameter name. This approach
aligns with PyIceberg’s existing naming convention for custom
implementations, such as `py-catalog-impl` (vs. `catalog-impl`
<https://github.com/apache/iceberg/blob/be6e9daf8901cdee63197e77fcf95624bb694f39/core/src/main/java/org/apache/iceberg/CatalogProperties.java#L27>)
for custom catalog implementations and `py-io-impl` (vs. `io-impl`
<https://github.com/apache/iceberg/blob/be6e9daf8901cdee63197e77fcf95624bb694f39/core/src/main/java/org/apache/iceberg/io/FileIOParser.java#L32>)
for custom FileIO implementations.

I’d like to propose formalizing the use of the `py-` prefix for
Python-specific configurations and extending this naming scheme to other
languages, such as Rust, Go, and C++. This would create a consistent,
predictable pattern for language-specific configuration parameters across
the project.

Looking forward to hearing your thoughts!

Best,
Kevin Liu

Reply via email to