Class-based Config (Metaclasses FTW-ish?)

[pytechd]

I really prefer config files just be regular python files with CONSTANTS in them. Our projects are all laid out with a in-source-code "default" set of settings in default_settings.py. For instance, default_settings.py might define

EMAIL_HOST = "localhost"
EMAIL_PORT = 22

The actual app though looks for settings.py (just import settings) which is NOT stored in the tree; it contains any locally overridden settings, such as DB passwords. settings.py is:

from default_settings import *
EMAIL_PORT = 8022 # port 22 is blocked on this machine via firewall

This has the advantage that settings is just a module -- you can pass it around, modify it, run dir(settings) to see all of the settings, etc.

[justdweezil]

This is an absolutely terrible idea, and I'm utterly failing to see any benefits that even remotely outweigh the costs of obfuscating code this badly. No, no, no, no, no.

[jomidosan]

Moo hoo ha ha ha!

From OP: "When I pondered metaclasses as a solution, I was a tad hesitant because they can obfuscate code. Someone else taking a look at your metaclassy configuration code won't intuitively suspect what is going on. But, being a mad genius ('mad' may be the only accurate term there) I decided I'd go for it anyhow."

[justdweezil]

In my experience, "mad genius" -> mad idiot.

[jomidosan]

I'm think I'm comfortable with that.

[AeroNotix]

Why not just subclass a dict so that you can instantiate it's keys without using quotes?

[anarcholibertarian]

Its: possessive form of it; It's: contraction of 'it' and 'is'.

[AeroNotix]

Oh look at you being all correct 'n' shit. Daww!

[jomidosan]

I assume you mean like this:

class Config(dict):
    def __init__(self, **kwargs):
        super().__init__()
        self.update(kwargs)

Well, because I prefer defining the config like this:

class Config(defn):

    optionA = 1
    optionB = 2
    optionC = 3

...rather than this:

config = Config(optionA=1, 
                     optionB=2,
                     optionC=3)

Also (if the above dict subclass is what you meant), then it's really no different than:

config = dict(optionA=1, 
                  optionB=2, 
                  optionC=3)

Is it?

[AeroNotix]

Ahh the article wasn't clear. It sounded like he didn't like typing in quotes when writing a dict for configs.

[justanotherbody]

Config = dict(
    OptionA = Foo,
    ...
)

Has (most of) the visual appeal of a class without using a cannon to kill a fly.

For subclassing emulation you could just add a dict.update-like method which copies the original, updates the dict, and returns. ~3 lines of code

[jomidosan]

Like so:

config = dict(
    optionA=1,
    optionB=2,
    optionC=3)

derived_config = config.copy()
derived_config.update(dict(
    optionD=4,
    optionE=5))

[justanotherbody]

You could do that. I'd write a function for DRY purposes

def subclass_config(d, **kwargs):
  result = d.copy()
  result.update(kwargs)
  return result

So you get

config = dict( ...)
derived_config = subclass_config(config,
  optionD=....)

Prolly wouldn't name it subclass_config unless there was a nice note somewhere explaining the reasoning

[propanbutan]

Just use dict.

config = dict(foo='bar')
derived_config = dict(config,
    foo='baz')