3 ms·

I once worked under someone who felt strongly about us importing modules instead of classes. So instead of from sklearn.feature_extraction.text import Tfi

I once worked under someone who felt strongly about us importing modules instead of classes. So instead of from sklearn.feature_extraction.text import TfidfVectorizer tfidf = TfidfVectorizer() we were told to change it to from sklearn.feature_extraction import text tfidf = text.TfidfVectorizer() to be compliant. Guess what variable name everyone used to store document text in every file. Until this article, I always blamed this on the decision to blindly import modules instead of... well... whatever makes sense. Now I'm realizing if we all avoid common names for packages then this whole class of issue goes away.

diggan 2y ago
> Until this article, I always blamed this on the decision to blindly import modules instead of... well... whatever makes sense. Now I'm realizing if we all avoided common names for packages then there would not have been an issue. If your solutions depends on others to "do the right thing", it often isn't a viable solution. However, how you import something in your own files, is something you most likely control.
- riskable 2y ago
  Having a global style policy (for imports) doesn't seem like relying on others to "do the right thing". It's just style and is completely arbitrary. Someone probably encountered a problem with having a mishmash of ways people do imports and thus began the policy. It's the type of policy where someone heaved a great big sigh and said, "this is why we can't have nice things."
  - diggan 2y ago
    I was specifically referring to the "Now I'm realizing if we all avoided common names for packages then there would not have been an issue" part as relying on others to do the right thing. Having a internal policy about how to import something wouldn't be relying on others to do the right thing.
riskable 2y ago
This is one of the benefits of having all your libraries/modules in a monolithic repo: You can refactor the names of everything pretty easily. It'd be a BIG commit but it's still a trivial task to rename something like `text` to `textual` or `text_anal` everywhere it's being used. I've done it before. It's the type of thing where you'll find out immediately if you screwed up somewhere but modern IDEs usually do a pretty good job at such things (the free version of PyCharm will do it real fast and then you never have to open it again if it's not your thing).
orlp 2y ago
> Now I'm realizing if we all avoid common names for packages then this whole class of issue goes away. The issue also just goes away if you just do it yourself with pretty much no effort: from sklearn.feature_extraction import text as feat_text tfidf = feat_text.TfidfVectorizer()

diggan 2y ago

> Until this article, I always blamed this on the decision to blindly import modules instead of... well... whatever makes sense. Now I'm realizing if we all avoided common names for packages then there would not have been an issue. If your solutions depends on others to "do the right thing", it often isn't a viable solution. However, how you import something in your own files, is something you most likely control.

riskable 2y ago
Having a global style policy (for imports) doesn't seem like relying on others to "do the right thing". It's just style and is completely arbitrary. Someone probably encountered a problem with having a mishmash of ways people do imports and thus began the policy. It's the type of policy where someone heaved a great big sigh and said, "this is why we can't have nice things."
- diggan 2y ago
  I was specifically referring to the "Now I'm realizing if we all avoided common names for packages then there would not have been an issue" part as relying on others to do the right thing. Having a internal policy about how to import something wouldn't be relying on others to do the right thing.

riskable 2y ago

This is one of the benefits of having all your libraries/modules in a monolithic repo: You can refactor the names of everything pretty easily. It'd be a BIG commit but it's still a trivial task to rename something like `text` to `textual` or `text_anal` everywhere it's being used. I've done it before. It's the type of thing where you'll find out immediately if you screwed up somewhere but modern IDEs usually do a pretty good job at such things (the free version of PyCharm will do it real fast and then you never have to open it again if it's not your thing).

orlp 2y ago

> Now I'm realizing if we all avoid common names for packages then this whole class of issue goes away. The issue also just goes away if you just do it yourself with pretty much no effort: from sklearn.feature_extraction import text as feat_text tfidf = feat_text.TfidfVectorizer()