in Django,
almost all the variables' naming style is UPPER_CASE_WITH_UNDERSCORES,
for instance:
INSTALLED_APPS = [
]
MIDDLEWARE_CLASSES = [
]
and so on...
what's the conventions it follows?
In addition to being constants and following PEP8, these constants are Django settings. Settings are defined in a settings module, and Django exposes an object, django.conf.settings, that proxies attributes in this module. The proxy object only exposes settings that are all uppercase.
So if you want your settings to be available on django.conf.settings, using uppercase variable names is not just a convention, it's required.
Pep8, its common across most python and PyCharm helps to enforce it.
In particular, this is the rule for constants
Constants are usually defined on a module level and written in all capital letters with underscores separating words. Examples include MAX_OVERFLOW and TOTAL.
It follows PEP 8.
The letters are upper case because they are constants. And the underscore is a usual python naming convention.
UPPER_CASE_WITH_UNDERSCORES
Django setting required uppercase letter for custom-defined settings variables
These are certain rules in Django for creating our own settings
Creating your own settings
There’s nothing stopping you from creating your own settings, for your own Django apps, but follow these guidelines:
Setting names must be all uppercase.
Don’t reinvent an already-existing setting.
For settings that are sequences, Django itself uses lists, but this is only a convention.
Please have a look at Django documentation - https://docs.djangoproject.com/en/3.0/topics/settings/
Django itself follows that rules and Naming convention in python like splits with the underscores are from pep8.
Related
I have subtly different entities that are important enough with respect to the relationships, flexibility, and expression of my schema that they warrant separate models.
How should I name/ case these?
a) Layerinput, Layerhidden, Layeroutput
b) Layer_Input, Layer_Hidden, Layer_Output
c) LayerInput, LayerHidden, LayerOutput
Right now I am leaning option a so that Django doesn't do anything too automagically incorrect with them, but that won't look great in documentation and code. Will use them with either DRF or graphql.
If you're referring to naming Classes, you should choose c) as shown in image below (obtained from https://docs.djangoproject.com/en/2.1/topics/db/models/#verbose-field-names).
If you're referring to the field_names (eg. name and age under the class CommonInfo in the figure above), then the convention for django is as followed:
According to PEP8 conventions,
Class names should normally use the CapWords convention.
These naming conventions are also followed in the Django framework. So you can choose the third option.
Use camelCase (option c), this helps you differentiate words in a variable while minimising the characters (as in option b)
Use this as a guide: https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/
CamelCase (option c) is also useful because Django will know how to render your model names in the admin site. For example 'LayerInput' will appear correctly as 'Layer input' without you having to specify it anywhere.
I'm upgrading to Django 1.8, and in one of my views I need to accept a parameter from the client that is set in the header.
In django 1.3 it was accessible by it's name, i.e:
{'HTTP_NAME_OF_PARAM':'value of parameter'}
And all was fine. However now, the header seems to look like this:
{'wsgi.input': <socket._fileobject object at 0x10ce09a50>}
So I need to get the data from this socket._fileobject in the header. How can I do that?
Thanks!
I shoud've mentioned that I use runserver for now, so I found this in the docs:
Note that runserver strips all headers with underscores in the name, so you won’t see them in META. This prevents header-spoofing based on ambiguity between underscores and dashes both being normalizing to underscores in WSGI environment variables. It matches the behavior of Web servers like Nginx and Apache 2.4+.
When changing the name to NAME-OF-PARAM it worked :)
What is the best naming convention for instance, url and template names of Django models with more than one word?
Instances
yetanothermodel = YetAnotherModel()
yet_another_model = YetAnotherModel()
Url names
'yetanothermodel_detail'
'yet_another_model_detail'
Template names
'yetanothermodel_detail.html'
'yet_another_model_detail.html'
It is your personal choice. But if you are working in a team I would say you should be applying the Python PEP8 standard of coding; that way all members of the team are using the same process and naming conventions to write their code.
In this instance:
yet_another_model = YetAnotherModel()
Variables names should be lower-case, underscore separated. With class names using the camel casing naming convention.
and
'yet_another_model_detail'
Url names should be treat like a variable name or function name, lower-case separated with _ (underscores).
Templates:
Whilst there is no defined naming convention for templates I treat the naming the same as a function name. So in these cases I go for lower-case with underscore word separation.
I also keep the templates inside of the django apps (sometimes, I will have a templates directory which will have a directory for each app name).
I also stick the CRUD type at the end of the filename.
For example:
<app_div>/user_profile.html
<app_dir>/user_profile_update.html
<app_dir>/user_profile_view.html
<app_dir>/user_profile_delete.html
In Rails 4 (which supports multilingual inflections), I can set:
config.i18n.default_locale = :es
in my config/application.rb, which allows me to do stuff like this in the console:
'general'.pluralize(:es) => "generales"
But when I run:
rails g model General conciencia:string atencion:string
Rails generates files with 'general' pluralized as 'generals' which in spanish should be 'generales'
Shouldn't Rails be using the multilingual inflector for its generators if the locale is set? Is there a way to force it to use them?
Thanks!
A bit late, but for the record: There's an argument in a Rails issue about why is it this way (so it's no a bug, but you can discuss it about):
Source: https://github.com/rails/rails/issues/10125#issuecomment-17274499
Up to Rails 4, the inflector had no support for multiple locales.
There was only one set of rules. The application has a default locale,
and in a i18n application each request may have a different locale,
but that didn't affect the inflector.
The inflector is not only used by the application, it is also used by
the framework to convert paths to class names, class names to tables,
create method names dynamically for the associations API, etc.
Obviously, those computations cannot vary. If your schema has a
"regions" table, Active Record has to map the Region class always to
the "regions" table, no matter the evolution of the application
(unless the schema changes, but the schema has to be visualized as
mostly static regarding to this, much more static that a configuration
option).
I have worked on applications that started development using :en, get
i18ned, and then switch to a default locale of :es. The locale is
something that affects the interface in that mindset. Everything
internal should work as it did before.
You should be able to change the default locale and everything else in
a way that does not affect static things like association names,
tables, routes, etc.
In could be the case that you have i18n routes (which change with the
locale of the request), but in general the statement above should be
true.
In order to be as backwards compatible as possible, we have left the
framework untouched, and have made the inflections to have a default
of :en so that existing applications get the same mappings after an
upgrade.
Django searches for messages files (.mo) in the order that is documented here:
https://docs.djangoproject.com/en/dev/topics/i18n/translation/#how-django-discovers-translations
Is it possible to have Django first search for messages files in the locale directory for the app that is currently being used?
I recently discoverd a bug in a project, that was caused by two apps having the same message-id but different translation. All the apps have their own locale directory.
I'm afraid this is not how django works for various reasons:
A single phrase should have a single translation. Django aside, this is a matter of gettext as well (the engine used for translation messages). Besides, it sounds normal to expect from a system to translate a single phrase with consistency in all pages. It still is the same phrase in the original language after all.
What would 'current application' mean? Is current application the one generating the current view? The translation itself might be coming from a module of another application. How to decide which of these two applications is appropriate? Translations can also be lazy which adds additional complexity to such decisions.
I suggest that you reorder your applications in INSTALLED_APPS to match the translation you prefer, or define a new translation messages path using the LOCALE_PATHS setting to provide a translation of your own.
Note: Technically, it is possible to override the default behavior in django.utils.translation.trans_real by providing a custom implementation of this module to change the behavior as you wish (it is the translation() method in this module that implements the selection algorithm). Then you should also override the Trans class originally defined in django.utils.translation.__init__ module to return your custom trans_real module (name this new class MyCustomTrans for example) and explicitly set it as the translation class somewhere in your project's init module, so that it loads early in the code:
from django.utils import translation
translation._trans = MyCustomTrans()
Now your custom algorithm would be used instead, but this would require a lot of work and in my opinion does not worth the hassle.