How much sanity checking is required for function inputs?

[Michael Selik]

On Sun, Apr 24, 2016, 1:51 AM Steven D'Aprano <steve at pearwood.info> wrote:

> On Sun, 24 Apr 2016 12:34 pm, Michael Torrie wrote:
>
> > There are many aspects to Pythonic programming, not just OOP.  For
> > example using modules to store shared state for your program components
> > is very pythonic, rather than using classes.  A module is kind of like a
> > singleton instance, and still is object-oriented by the way (the module
> > is an object).
>
> I find myself going backwards and forwards on whether or not that is a good
> idea. I think it depends on whether you are writing a library or an
> application.
>
> If you're writing an application, then storing state in module-level
> variables works fine. Your application is, effectively, a singleton, and if
> you try to run it twice, you'll (probably) be running it in two distinct
> processes, so that's okay.
>
> (If you're not, if somehow you perform some sort of trickery where you have
> a single Python interpreter running your script twice in the same process,
> then it will break horribly. But if you can do that, you're living on the
> edge already and can probably deal with it.)
>
> But if you're writing a library, then using module state is a Bad Idea.
> Your
> library may be used by more than one client in the same process, and they
> will conflict over each other's library-level state. "Global variables
> considered harmful."
>

I think we're giving mixed messages because we're conflating "constants"
and globals that are expected to change.

In our case here, I think two clients in the same process sharing state
might be a feature rather than a bug. Or at least it has the same behavior
as the current implementation.

>