On 8/30/2018 9:43 AM, Steven D'Aprano wrote:
> On Thu, 30 Aug 2018 06:01:26 -0700, Tim wrote:
>> I saw a thread on reddit/python where just about everyone said they
>> never put code in their __init__ files.
> Pfft. Reddit users. They're just as bad as Stackoverflow users. *wink*
>> Here's a stackoverflow thread saying the same thing.
>> That's new to me. I like to put functions in there that other modules
>> within the module need. Thought that was good practice DRY and so forth.
> Its fine to put code in __init__.py files.
> If the expected interface is for the user to say:
> result = package.spam()
> then in the absence of some specific reason why spam needs to be in a
> submodule, why shouldn't it go into package/__init__.py ?
> Of course it's okay for the definition of spam to be in a submodule, if
> necessary. But it shouldn't be mandatory.
>> And I never do 'from whatever import *' Ever.
>> The reddit people said they put all their stuff into different modules
>> and leave init empty.
> Did any one of them state *why* they do this? What benefit is there to
> make this a hard rule?
> Did anyone mention what the standard library does?
> Check out the dbm, logging, html, http, collections, importlib, and
> curses packages (and probably others):
tkinter.__init__ has 'from tkinter.constants import *' and has the code
defining tk widgets, among other things. tkinter/ has submodules for
ttk, fonts, and other optional facilities. The setup is partly for
historical reasons, but is partly intended and not a bad design for a
module with 'main' stuff and 'optional' stuff.
The user interface would be the same if widget code were in
tkinter.widgets with .__init__ containing 'from tkinter.widgets import *'.
Terry Jan Reedy