dstandish commented on PR #29905:
URL: https://github.com/apache/airflow/pull/29905#issuecomment-1550119067
> The import is `from airflow.providers.cncf.kubernetes.operators.pod import
KubernetesPodOperator`
>
> You know it's Kubernetes because you import it from Kubernetes provider.
There is no reason to have `kubernetes_` for all `py` file in the provider.
Yea I guess my interpretation of AIP-21 was not that we avoid all redundancy
(and hooks is a good example where we don't do this, because then your file is
`_.py`) but a rule about how to map to module name from class name. So FtpHook
becomes ftp.py, KubernetesPodOperator becomes kubernetes_pod.py -- and indeed,
someone in the past must have also shared this interpretation when it was
originally renamed from `kubernetes_pod_operator.py` to `kubernetes_pod.py`.
I see the logic, that from organization perspective, the information
("kubernetes") is there in the module path, so in that sense you can say it's
not necessary. I guess I'm with Jarek in preferring the verbosity -- and like
he was mentioning, it's nice for finding a file, e.g.:
<img width="742" alt="image"
src="https://github.com/apache/airflow/assets/15932138/2db791b5-9a34-4c06-9c2e-8c4f216b2344";>
vs
<img width="742" alt="image"
src="https://github.com/apache/airflow/assets/15932138/7f49ffb2-1816-4103-bd84-5259d95af055";>
But I am also with Jarek in the sense of not standing in the way of the
shorter naming if that's what the community prefers.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
