3 ms·

I have the unfortunate "luck" to be using a Python library at work that _loves_ to use import side-effects. Importing it like God intended makes it parse comman

I have the unfortunate "luck" to be using a Python library at work that _loves_ to use import side-effects. Importing it like God intended makes it parse command-line arguments and fail if it doesn't like what was passed in. And that's just the start. Nearly every __init__.py has code in it, including class definitions. I have no idea why.

mercurial 13y ago
It's like programmers who find out about metaprogramming. Usually they grow out of it.
- atilaneves 13y ago
  I haven't grown out of metaprogramming at all. I just try and use it only when it's the best option. Usually because it means reducing duplication. I liked metaprogramming to an extent in C++. I _love_ it in D.
  - gbog 13y ago
    Replace "best option" with "only practical option" and you're good to go.
    - einhverfr 13y ago
      That may depend on the language you are using.
- einhverfr 13y ago
  In Perl, I find metaprogramming to be extremely powerful. I don't go too deep into Class::MOP usually. However, I do find that focusing on tooling before code is usually a net win. This means a lot of work can be done by writing DSL's that use metaprogramming behind the scenes. It works well and has become a common approach for certain kind of things (like object frameworks).
  - mercurial 13y ago
    I'm not saying you should never use metaprogramming. Sometimes there is no other (practical) way. But it can be easily abused, often for a little added convenience but a much larger conceptual complexity and additional debugging issues. Why have a well-designed API when you can have a metaprogrammmed mess instead?
bjt 13y ago
In case a non-Python programmer is reading this and misunderstood your comment, I'll point out that having code in __init__.py and having import-time side effects are completely unrelated. When I put any code in __init__.py, it's usually just to make the import path shorter for the programmer using my library. So instead of this: from mypackage.models import Foo ...users can do this: from mypackage import Foo And all it takes to support that is putting this in mypackage/__init__.py: from mypackage.models import Foo A quick Googling of "Should I put code in __init__.py" shows a lot of people doing that same pattern. It doesn't show a consensus of people saying that more substantial code in __init__.py is an anti-pattern.
- atilaneves 13y ago
  To me you're using __init__.py right. The person who wrote the library I mentioned really isn't.

mercurial 13y ago

It's like programmers who find out about metaprogramming. Usually they grow out of it.

atilaneves 13y ago
I haven't grown out of metaprogramming at all. I just try and use it only when it's the best option. Usually because it means reducing duplication. I liked metaprogramming to an extent in C++. I _love_ it in D.
- gbog 13y ago
  Replace "best option" with "only practical option" and you're good to go.
  - einhverfr 13y ago
    That may depend on the language you are using.
einhverfr 13y ago
In Perl, I find metaprogramming to be extremely powerful. I don't go too deep into Class::MOP usually. However, I do find that focusing on tooling before code is usually a net win. This means a lot of work can be done by writing DSL's that use metaprogramming behind the scenes. It works well and has become a common approach for certain kind of things (like object frameworks).
- mercurial 13y ago
  I'm not saying you should never use metaprogramming. Sometimes there is no other (practical) way. But it can be easily abused, often for a little added convenience but a much larger conceptual complexity and additional debugging issues. Why have a well-designed API when you can have a metaprogrammmed mess instead?

bjt 13y ago

In case a non-Python programmer is reading this and misunderstood your comment, I'll point out that having code in __init__.py and having import-time side effects are completely unrelated. When I put any code in __init__.py, it's usually just to make the import path shorter for the programmer using my library. So instead of this: from mypackage.models import Foo ...users can do this: from mypackage import Foo And all it takes to support that is putting this in mypackage/__init__.py: from mypackage.models import Foo A quick Googling of "Should I put code in __init__.py" shows a lot of people doing that same pattern. It doesn't show a consensus of people saying that more substantial code in __init__.py is an anti-pattern.

atilaneves 13y ago
To me you're using __init__.py right. The person who wrote the library I mentioned really isn't.