How much sanity checking is required for function inputs?

Stephen Hansen me at ixokai.io
Fri Apr 22 01:25:24 EDT 2016


On Thu, Apr 21, 2016, at 08:33 PM, Christopher Reimer wrote:
> On 4/21/2016 7:20 PM, Stephen Hansen wrote:
> > I... that... what... I'd forget that link and pretend you never went
> > there. Its not helpful.
> 
> I found it on the Internet, so it must be true -- and Pythonic at that!

My advice is to not look at that site further. I can't count the number
of things that are just... not useful or helpful. 

Directly translating the Gang of Four Design Pattern book to Python
doesn't generally result in useful ideas, except in certain abstractions
like the visitor pattern when you're designing big systems. 



> 
> > What's the contents of this big dictionary that has everything in it 
> > for some reason?
> 
> Keep in mind that I'm coming from a Java background (not by choice) with 
> a smattering of C programming. I initially had ALL THESE CONSTANTS in 
> different parts of my code and couldn't easily use them across different 
> modules. I didn't like all these constants, created a singleton class 
> that uses ConfigParser, dumped everything into a .ini file, and accessed 
> from in each module. As I learn to write Pythonic code, the constants 
> may go away. Switching from my original code to the factory method 
> eliminated a half-dozen constants.

I'm not criticizing, I'm *asking* in the hopes you'll explain what
you're doing better, so I can understand and give advice that's more
relevant: I don't understand what it is you're doing with the VARS or
const dictionary. Even with your explanation here, I don't get it. 

Why do you need to read VARS["COLOR_BLACK"] or the new
const["COLOR_BLACK"} from a configuration file? How is this stuff
configurable? 

Why not, 'color in ("black", "white")'?

The only reason I can think of why you'd want to read what is "black" or
"white" out of a configuration file is internationalization, and if
that's your aim, there's a couple really good projects I can recommend
that solve that issue better. 

I can't think of any reason why you'd want a structure like:
struct = {}
struct["COLOR_BLACK"] = "black"
struct["COLOR_WHITE"] = "white"

"black" is a perfectly good way to express "black", you have this
indirection/abstraction for a reason I don't understand. Granted, maybe
this is a heavy javaism, and I'm utterly ignorant of Java, but my C/C++
mind can't think of a reason for this either.

That said, if you're wanting to share constants across different parts
of your code, use a module.

Create a module, say, things.py, that itself doesn't import other
things, and it says:

black = "Black"
white = "White"

(Bear in mind I still don't know why you want or need this indirection)

Then you "import things" and refer to those constants as things.black,
things.white.

You can then "if color in (things.black, things.white)". Maybe even "if
color in things.colors" if in your things file you have things = (black,
white).

Modules are great for sharing information. The admonition of GLOBALS R
BAD is not as strong in Python as you find in some other languages.
(Don't take that to mean GLOBALS R GUD, granted. Passing state is best
when it makes sense).

--S
m e @ i x o k a i . i o



More information about the Python-list mailing list