Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #107531 > unrolled thread

Re: How much sanity checking is required for function inputs?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: How much sanity checking is required for function inputs? Michael Torrie <torriem@gmail.com> - 2016-04-23 20:34 -0600
    Re: How much sanity checking is required for function inputs? Steven D'Aprano <steve@pearwood.info> - 2016-04-24 15:49 +1000
      Re: How much sanity checking is required for function inputs? Michael Selik <michael.selik@gmail.com> - 2016-04-24 06:40 +0000
        Re: How much sanity checking is required for function inputs? Steven D'Aprano <steve@pearwood.info> - 2016-04-25 04:00 +1000
          Re: How much sanity checking is required for function inputs? Michael Selik <michael.selik@gmail.com> - 2016-04-25 01:02 +0000

#107531 — Re: How much sanity checking is required for function inputs?

On 04/23/2016 07:45 PM, Christopher Reimer wrote:
> I had to confront all the bad habits I brought over Java and change my 
> code to be more Pythonic. This is where I started having fun, learning 
> the tricks and collapsing multi-line code into a single line code. I've 
> learned more about Python in the few weeks than I had in two years of 
> writing procedural scripts and translating BASIC goto hell.

Procedural programming does not necessarily mean BASIC-style goto hell.
Not sure why you would think that.  In fact that's not really what
procedural programming is about.  However, Mr. Selik wasn't advocating
procedural programming at all.  Not defining a class does not make your
code precdural.  But using classes does not mean your code is *not*
procedural. If you are using an event-driven framework then I will say,
yes your code is not procedural.

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).  Sadly Java really messed up people by using classes as a
namespace mechanism.  That was quite a mistake.  Really messed with
people's expectations of OOP.

I would say that pythonic programming involves defining classes when
it's appropriate, and not doing so when something else will work just as
well and be simpler.

[toc] | [next] | [standalone]

#107537

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."



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#107540

On Sun, Apr 24, 2016, 1:51 AM Steven D'Aprano <steve@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.

>

[toc] | [prev] | [next] | [standalone]

#107559

On Sun, 24 Apr 2016 04:40 pm, Michael Selik wrote:


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

When you talk about "state", that usually means "the current state of the
program", not constants. math.pi is not "state".


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

I don't think so. Two clients sharing state is exactly what makes thread
programming with shared state so exciting.

Suppose you import the decimal module, and set the global context:

py> import decimal
py> decimal.setcontext(decimal.ExtendedContext)
py> decimal.getcontext().prec = 18
py> decimal.Decimal(1)/3
Decimal('0.333333333333333333')

Great. Now a millisecond later you do the same calculation:

py> decimal.Decimal(1)/3
Decimal('0.33333')


WTF just happened here??? The answer is, another client of the module, one
you may not even know about, has set the global context:

decimal.getcontext().prec = 5

and screwed you over but good.




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#107578

On Sun, Apr 24, 2016 at 2:08 PM Steven D'Aprano <steve@pearwood.info> wrote:

> On Sun, 24 Apr 2016 04:40 pm, Michael Selik wrote:
> > I think we're giving mixed messages because we're conflating
> "constants" and globals that are expected to change.
>
> When you talk about "state", that usually means "the current state of the
> program", not constants. math.pi is not "state".
>

Perhaps I was unclear. You provided an example of what I was trying to
point out.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web