We Keep Coding

Passing string rather than function in django url pattern

In the Django docs it says about url patterns:
It is possible to pass a string containing the path to a view rather
than the actual Python function object. This alternative is supported
for the time being, though is not recommended and will be removed in a
future version of Django.
Does anyone have any insight as to why this the case? I find this alternative to be quite handy and can't find anything explaining why this is a bad (or, at least, less than ideal) idea.

I think the 1.8 Release Notes in the repo explains it quite well. Here's a summary of the main points:
In the modern era, we have updated the tutorial to instead recommend importing
your views module and referencing your view functions (or classes) directly.
This has a number of advantages, all deriving from the fact that we are using
normal Python in place of "Django String Magic": the errors when you mistype a
view name are less obscure, IDEs can help with autocompletion of view names,
etc.
Thus patterns() serves little purpose and is a burden when teaching new users
(answering the newbie's question "why do I need this empty string as the first
argument to patterns()?"). For these reasons, we are deprecating it.
Updating your code is as simple as ensuring that urlpatterns is a list of
:func:django.conf.urls.url instances.

Django template not loaded when deploy on openshift

Totally new to Openshift and has been following various stepbystep guides. Able to get django 1.6, Python 2.7 and Mezzanine 3.0.9 up with the application working - partially. For some reason, the template is not loaded, both if the template is part of a HTML include tag or a part of view.py.
When tailing access-log, cannot see errors or anything to go by. The settings.py has
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
PROJECT_DIRNAME = PROJECT_ROOT.split(os.sep)[-1]
TEMPLATE_DIRS = (os.path.join(PROJECT_ROOT, "templates"),)
It seems to not be able to find the path of the template files but don't know why as the value of TEMPLATE_DIRS seems to be correct when checking it. Everything is working ok on my local machine but not on Openshift. Any pointers are much appreciated as have been googling and search around for a few days and still get no where.
Thank you.
EDIT:
Decide to turn on DEBUG mode and that is a lot clearer to investigate. Turns out that without providing absolute module name when importing a method the application just fail but this is not the case on local machine.
e.g. instead of providing
from projectname.appname.view import some_function
I was putting
from appname.view import some_function
Silly me. That teach me a good few days lesson!!!durr!!

Problem is resolved by providing a full module name to the import statement.
e.g.
from projectname.appname.view import some_function
I had, see below, and that caused the issue.
from appname.view import some_function
Once a full module name is provided, it all works perfectly.
Thank you.

How can you define a persistent variable in Django

I have a Django project, and what I would like to do is be able to create a reference to a variable defined in urls.py that is kept for the duration of the process.
I've tried an approach using global vars - but for whatever reason, the value of the variable in urls.py is the initial value - even if I change it somewhere else. I've followed the concepts as explained here, but just doesn't work.
However, when I try such a scenario outside of Django, it works as expected.
I think I'm missing a trick (or two) with Django - it's great, I'm new to it, and I think I'm going down the wrong path. Should I be using the caching stuff included with Django to store the variable, or is that even more off track?
Many thanks for any pointers.

I agree with S.Lott's comment, your question is a little vague. I think you're trying to reference some variable defined in urls? You know you can import urls.py into any other python script as long as it's on your PYTHONPATH. Assuming you're talking about a Django view when you say a "process", you could import a URL directly into a view function:
def foo_view(request):
from bar_app.urls import BAR_URL_PATTERN
Please give us more information on your specific use case, and I'll amend my answer to give you a better response.
Good Luck! I hope you're enjoying your first foray into the wonderful world of Django!

Using and Installing Django Custom Field Models

I found a custom field model (JSONField) that I would like to integrate into my Django project.
Where do I actually put the JSONField.py file? -- Would it reside in my Django project or would I put it in something like: /django/db/models/fields/
Since I assume it can be done multiple ways, would it then impact how JSONField (or any custom field for that matter) would get imported into my models.py file as well?

It's worth remembering that Django is just Python, and so the same rules apply to Django customisations as they would for any other random Python library you might download. To use a bit of code, it has to be in a module somewhere on your Pythonpath, and then you can just to from foo import x.
I sometimes have a lib directory within my Django project structure, and put into it all the various things I might need to import. In this case I might put the JSONField code into a module called fields, as I might have other customised fields.
Since I know my project is already on the Pythonpath, I can just do from lib.fields import JSONField, then I can just do myfield = JSONField(options) in the model definition.

For the first question, I would rather not put it into django directory, because in case of upgrades you may end up loosing all of your changes. It is a general point: modifying an external piece of code will lead to increased maintenance costs.
Therefore, I would suggest you putting it into some place accessible from your pythonpath - it could be a module in your project, or directly inside the site-packages directory.
As about the second question, just "installing" it will not impact your existing models.
You have to explicitly use it, by either by adding it to all of your models that need it, either by defining a model that uses it, and from whom all of your models will inherit.

The best thing would be to keep Django and customizations apart. You could place the file anywhere on your pythonpath really

Is it ever polite to put code in a python configuration file?

One of my favorite features about python is that you can write configuration files in python that are very simple to read and understand. If you put a few boundaries on yourself, you can be pretty confident that non-pythonistas will know exactly what you mean and will be perfectly capable of reconfiguring your program.
My question is, what exactly are those boundaries? My own personal heuristic was
Avoid flow control. No functions, loops, or conditionals. Those wouldn't be in a text config file and people aren't expecting to have understand them. In general, it probably shouldn't matter the order in which your statements execute.
Stick to literal assignments. Methods and functions called on objects are harder to think through. Anything implicit is going to be a mess. If there's something complicated that has to happen with your parameters, change how they're interpreted.
Language keywords and error handling are right out.
I guess I ask this because I came across a situation with my Django config file where it seems to be useful to break these rules. I happen to like it, but I feel a little guilty. Basically, my project is deployed through svn checkouts to a couple different servers that won't all be configured the same (some will share a database, some won't, for example). So, I throw a hook at the end:
try:
from settings_overrides import *
LOCALIZED = True
except ImportError:
LOCALIZED = False
where settings_overrides is on the python path but outside the working copy. What do you think, either about this example, or about python config boundaries in general?

There is a Django wiki page, which addresses exactly the thing you're asking.
http://code.djangoproject.com/wiki/SplitSettings
Do not reinvent the wheel. Use configparser and INI files. Python files are to easy to break by someone, who doesn't know Python.

Your heuristics are good. Rules are made so that boundaries are set and only broken when it's obviously a vastly better solution than the alternate.
Still, I can't help but wonder that the site checking code should be in the parser, and an additional configuration item added that selects which option should be taken.
I don't think that in this case the alternative is so bad that breaking the rules makes sense...
-Adam

I think it's a pain vs pleasure argument.
It's not wrong to put code in a Python config file because it's all valid Python, but it does mean you could confuse a user who comes in to reconfigure an app. If you're that worried about it, rope it off with comments explaining roughly what it does and that the user shouldn't edit it, rather edit the settings_overrides.py file.
As for your example, that's nigh on essential for developers to test then deploy their apps. Definitely more pleasure than pain. But you should really do this instead:
LOCALIZED = False
try:
from settings_overrides import *
except ImportError:
pass
And in your settings_overrides.py file:
LOCALIZED = True
... If nothing but to make it clear what that file does.. What you're doing there splits overrides into two places.

As a general practice, see the other answers on the page; it all depends. Specifically for Django, however, I see nothing fundamentally wrong with writing code in the settings.py file... after all, the settings file IS code :-)
The Django docs on settings themselves say:
A settings file is just a Python module with module-level variables.
And give the example:
assign settings dynamically using normal Python syntax. For example:
MY_SETTING = [str(i) for i in range(30)]

Settings as code is also a security risk. You import your "config", but in reality you are executing whatever code is in that file. Put config in files that you parse first and you can reject nonsensical or malicious values, even if it is more work for you. I blogged about this in December 2008.