potiuk commented on PR #29905:
URL: https://github.com/apache/airflow/pull/29905#issuecomment-1549224491

   I think (and this is why I approve it) - this change was really going 
together with the "spirit" of the AIP 21 even if not necessarily the "letter" 
of it.
   
   The spirit of AIP-21 was that we remove redundant, repeated names from the 
full path of the class/module.  That was the gist of it and the reason we 
implemented the change.
   
   And In this case. the change was rather following that:
   
   ```
   from airflow.providers.cncf.kubernetes.operators.kubernetes_pod import 
KubernetesPodOperator
   ```
   
   contains `kubernetes` 3 times. 
   
   To be perfectly honest, I have not agreed with the change when we 
implemented it. I was against shortening the imports because I though that 
rather than length of the imports, the important thing is that when I press 
SHIFT (search anywhere) three times in my IntelliJ IDE and start typing 
`datadog`  I can see `datadog_operators.py`, `datadog_hooks.py`, 
`datadog_sensors.py` rather than three `datadog.py` so that I can choose the 
one I want easier. It was made easier (actually during our discussion back 
then) that Intellij started to also show PATH in the result of the search so I 
did not oppose that much and went into "disagree but engage" mode (but it 
somewhat haunts me till today even though it is pretty usable even now with 
those shorter names):
   
   
![image](https://github.com/apache/airflow/assets/595491/e36f2b23-d94b-4576-a2c9-6b981975b9f1)
   
   
   I **think** this is just a natural application to be more consistent there. 
Again - I would personally prefer to go with the `kubernetes_` prefix but the 
spirit of AIP-21 was to optimise the import length and reduce redundancy and 
for consistency, I think it makes sense to use the `pod.py` 
   
    
   
   
   
   
   


-- 
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]

Reply via email to