Thanks! Very clear and helpful. Mark On Feb 14, 2014 9:54 AM, "Bill Freeman" <[email protected]> wrote:
> It depends on the complexity of the issue. > > The price of gold does fluctuate. On the grounds that I might want to > change it more often than I would want to ssh in, edit a file, and restart, > I would tend to put price of gold in the database, that is, in a model of > which there may only be one instance. Implementing limits on who has > permission to change it is a separate fun topic, which may not be needed if > very few people have admin logins. > > Then there are application specific configuration options, which tent to > never change once an installation is up and running. You can require that > they be set in settings.py if the constants are highly likely to differ > site to site (or if there is only one site in the world using this app), > but it is probably worthwhile providing defaults which can be overridden in > settings.py . A common way to do the latter is to have another settings > file in the app directory (usually also called settings.py, since it can be > qualified with the app name) which defines constants as the result of > calling gettattr on the main settings object, and providing the default > value as teh third argument to getattr. The other parts of the app get the > constants from the app specific settings file. > > Another kind of constant is truly never expected to change, such as > physical or algorithmic constants, defined so that they can be used > symbolically. Sometimes they are only used quite locally, and can be > defined in that module, but if they are used by two or more modules, they > should probably be defined once, and imported in modules that use them. > While it is possible to define them in any module (such as the one that > uses them the most) and to import from that module in others that need the > constant(s), you must beware of circular import problems, so it is often > easier to create a constants.py or the like (if you already have an app > specific settings module, it is a fine place for you constants). But your > models.py module, if you have only one, is a pretty safe place to put > constants, since it doesn't tend to import your other modules (unless you > have an app specific settings module), so you won't (typically) have > circularity if you import from it. > > Bill > > > On Fri, Feb 14, 2014 at 11:13 AM, Mark Phillips < > [email protected]> wrote: > >> Where should one put application specific constants - those that change >> sometimes(1) and those that never change? For example, I am creating a >> simple inventory application for my mother's estate. Several quotes for >> her jewelry are based on the weight of the jewelry and the current price of >> gold. >> >> In the Estimate model, I have a field for weight, and then a property >> that looks something like: >> >> @property >> def estimate_by_weight(): >> return self.weight * PRICE_OF GOLD >> >> Where would I put the PRICE_OF_GOLD constant? Some ideas that came to >> mind: >> >> 1. Settings.py - but then I have to edit that file every time I want to >> update the price of gold >> >> 2. Maybe a model so I can update it in the admin screens? >> >> 3. A form somewhere? But I think this would mean a model, so this is >> probably the same as #2. >> >> Where would one put a non-changing constant like the speed of light in a >> django application? >> >> Thanks! >> >> Mark >> >> (1) Yes, I realize that terms 'constant' and 'changes sometimes' are >> mutually exclusive, but I hope you get the gist of what I am asking >> regardless of my imprecise description.. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/django-users. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/CAEqej2OuRC%3D5c2AwKkLRV0%2BGQJMBd6g2wM41mRZB1RCpMtOshw%40mail.gmail.com >> . >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CAB%2BAj0tCsz6XSb4T4gziZFzUxG%3DnHxmMe_Zj7n%3D3P%3DgEZ7s7rQ%40mail.gmail.com > . > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAEqej2NzsqyYidunDEHuD8%3DAjCHkUNTW08XX6CgqJJjJXdQLJA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
