neulab/docprompting-conala huggingface dataset:
class Engine(dirs=None, app_dirs=False, context_processors=None, debug=False, loaders=None, string_if_invalid='', file_charset='utf-8', libraries=None, builtins=None, autoescape=True)  
When instantiating an Engine all arguments must be passed as keyword arguments:  
dirs is a list of directories where the engine should look for template source files. It is used to configure filesystem.Loader. It defaults to an empty list.  
app_dirs only affects the default value of loaders. See below. It defaults to False.  
autoescape controls whether HTML autoescaping is enabled. It defaults to True.  Warning Only set it to False if you’re rendering non-HTML templates!   
context_processors is a list of dotted Python paths to callables that are used to populate the context when a template is rendered with a request. These callables take a request object as their argument and return a dict of items to be merged into the context. It defaults to an empty list. See RequestContext for more information.  
debug is a boolean that turns on/off template debug mode. If it is True, the template engine will store additional debug information which can be used to display a detailed report for any exception raised during template rendering. It defaults to False.  
loaders is a list of template loader classes, specified as strings. Each Loader class knows how to import templates from a particular source. Optionally, a tuple can be used instead of a string. The first item in the tuple should be the Loader class name, subsequent items are passed to the Loader during initialization. It defaults to a list containing:  'django.template.loaders.filesystem.Loader' 
'django.template.loaders.app_directories.Loader' if and only if app_dirs is True.  If debug is False, these loaders are wrapped in django.template.loaders.cached.Loader. See Loader types for details.  
string_if_invalid is the output, as a string, that the template system should use for invalid (e.g. misspelled) variables. It defaults to the empty string. See How invalid variables are handled for details.  
file_charset is the charset used to read template files on disk. It defaults to 'utf-8'.  
'libraries': A dictionary of labels and dotted Python paths of template tag modules to register with the template engine. This is used to add new libraries or provide alternate labels for existing ones. For example: Engine(
    libraries={
        'myapp_tags': 'path.to.myapp.tags',
        'admin.urls': 'django.contrib.admin.templatetags.admin_urls',
    },
)
 Libraries can be loaded by passing the corresponding dictionary key to the {% load %} tag.  
'builtins': A list of dotted Python paths of template tag modules to add to built-ins. For example: Engine(
    builtins=['myapp.builtins'],
)
 Tags and filters from built-in libraries can be used without first calling the {% load %} tag.
Engine.from_string(template_code)  
Compiles the given template code and returns a Template object.
Engine.get_template(template_name)  
Loads a template with the given name, compiles it and returns a Template object.
Engine.select_template(template_name_list)  
Like get_template(), except it takes a list of names and returns the first template that was found.
engines  
Template engines are available in django.template.engines: from django.template import engines

django_engine = engines['django']
template = django_engine.from_string("Hello {{ name }}!")
 The lookup key — 'django' in this example — is the engine’s NAME.
get_template(template_name, using=None)  
This function loads the template with the given name and returns a Template object. The exact type of the return value depends on the backend that loaded the template. Each backend has its own Template class. get_template() tries each template engine in order until one succeeds. If the template cannot be found, it raises TemplateDoesNotExist. If the template is found but contains invalid syntax, it raises TemplateSyntaxError. How templates are searched and loaded depends on each engine’s backend and configuration. If you want to restrict the search to a particular template engine, pass the engine’s NAME in the using argument.
render_to_string(template_name, context=None, request=None, using=None)  
render_to_string() loads a template like get_template() and calls its render() method immediately. It takes the following arguments.  
template_name  The name of the template to load and render. If it’s a list of template names, Django uses select_template() instead of get_template() to find the template. 
context  A dict to be used as the template’s context for rendering. 
request  An optional HttpRequest that will be available during the template’s rendering process. 
using  An optional template engine NAME. The search for the template will be restricted to that engine.  Usage example: from django.template.loader import render_to_string
rendered = render_to_string('my_template.html', {'foo': 'bar'})
select_template(template_name_list, using=None)  
select_template() is just like get_template(), except it takes a list of template names. It tries each name in order and returns the first template that exists.
class app_directories.Loader  
Loads templates from Django apps on the filesystem. For each app in INSTALLED_APPS, the loader looks for a templates subdirectory. If the directory exists, Django looks for templates in there. This means you can store templates with your individual apps. This also helps to distribute Django apps with default templates. For example, for this setting: INSTALLED_APPS = ['myproject.polls', 'myproject.music']
 …then get_template('foo.html') will look for foo.html in these directories, in this order:  /path/to/myproject/polls/templates/ /path/to/myproject/music/templates/  … and will use the one it finds first. The order of INSTALLED_APPS is significant! For example, if you want to customize the Django admin, you might choose to override the standard admin/base_site.html template, from django.contrib.admin, with your own admin/base_site.html in myproject.polls. You must then make sure that your myproject.polls comes before django.contrib.admin in INSTALLED_APPS, otherwise django.contrib.admin’s will be loaded first and yours will be ignored. Note that the loader performs an optimization when it first runs: it caches a list of which INSTALLED_APPS packages have a templates subdirectory. You can enable this loader by setting APP_DIRS to True: TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'APP_DIRS': True,
}]
class Loader  
Loads templates from a given source, such as the filesystem or a database.  
get_template_sources(template_name)  
A method that takes a template_name and yields Origin instances for each possible source. For example, the filesystem loader may receive 'index.html' as a template_name argument. This method would yield origins for the full path of index.html as it appears in each template directory the loader looks at. The method doesn’t need to verify that the template exists at a given path, but it should ensure the path is valid. For instance, the filesystem loader makes sure the path lies under a valid template directory. 
  
get_contents(origin)  
Returns the contents for a template given a Origin instance. This is where a filesystem loader would read contents from the filesystem, or a database loader would read from the database. If a matching template doesn’t exist, this should raise a TemplateDoesNotExist error. 
  
get_template(template_name, skip=None)  
Returns a Template object for a given template_name by looping through results from get_template_sources() and calling get_contents(). This returns the first matching template. If no template is found, TemplateDoesNotExist is raised. The optional skip argument is a list of origins to ignore when extending templates. This allow templates to extend other templates of the same name. It also used to avoid recursion errors. In general, it is enough to define get_template_sources() and get_contents() for custom template loaders. get_template() will usually not need to be overridden.
get_contents(origin)  
Returns the contents for a template given a Origin instance. This is where a filesystem loader would read contents from the filesystem, or a database loader would read from the database. If a matching template doesn’t exist, this should raise a TemplateDoesNotExist error.
get_template(template_name, skip=None)  
Returns a Template object for a given template_name by looping through results from get_template_sources() and calling get_contents(). This returns the first matching template. If no template is found, TemplateDoesNotExist is raised. The optional skip argument is a list of origins to ignore when extending templates. This allow templates to extend other templates of the same name. It also used to avoid recursion errors. In general, it is enough to define get_template_sources() and get_contents() for custom template loaders. get_template() will usually not need to be overridden.
get_template_sources(template_name)  
A method that takes a template_name and yields Origin instances for each possible source. For example, the filesystem loader may receive 'index.html' as a template_name argument. This method would yield origins for the full path of index.html as it appears in each template directory the loader looks at. The method doesn’t need to verify that the template exists at a given path, but it should ensure the path is valid. For instance, the filesystem loader makes sure the path lies under a valid template directory.
class cached.Loader  
By default (when DEBUG is True), the template system reads and compiles your templates every time they’re rendered. While the Django template system is quite fast, the overhead from reading and compiling templates can add up. You configure the cached template loader with a list of other loaders that it should wrap. The wrapped loaders are used to locate unknown templates when they’re first encountered. The cached loader then stores the compiled Template in memory. The cached Template instance is returned for subsequent requests to load the same template. This loader is automatically enabled if OPTIONS['loaders'] isn’t specified and OPTIONS['debug'] is False (the latter option defaults to the value of DEBUG). You can also enable template caching with some custom template loaders using settings like this: TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'DIRS': [BASE_DIR / 'templates'],
    'OPTIONS': {
        'loaders': [
            ('django.template.loaders.cached.Loader', [
                'django.template.loaders.filesystem.Loader',
                'django.template.loaders.app_directories.Loader',
                'path.to.custom.Loader',
            ]),
        ],
    },
}]
  Note All of the built-in Django template tags are safe to use with the cached loader, but if you’re using custom template tags that come from third party packages, or that you wrote yourself, you should ensure that the Node implementation for each tag is thread-safe. For more information, see template tag thread safety considerations.
class filesystem.Loader  
Loads templates from the filesystem, according to DIRS. This loader is enabled by default. However it won’t find any templates until you set DIRS to a non-empty list: TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'DIRS': [BASE_DIR / 'templates'],
}]
 You can also override 'DIRS' and specify specific directories for a particular filesystem loader: TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'OPTIONS': {
        'loaders': [
            (
                'django.template.loaders.filesystem.Loader',
                [BASE_DIR / 'templates'],
            ),
        ],
    },
}]
class locmem.Loader  
Loads templates from a Python dictionary. This is useful for testing. This loader takes a dictionary of templates as its first argument: TEMPLATES = [{
    'BACKEND': 'django.template.backends.django.DjangoTemplates',
    'OPTIONS': {
        'loaders': [
            ('django.template.loaders.locmem.Loader', {
                'index.html': 'content here',
            }),
        ],
    },
}]
 This loader is disabled by default.
SimpleTemplateResponse.__init__(template, context=None, content_type=None, status=None, charset=None, using=None, headers=None)  
Instantiates a SimpleTemplateResponse object with the given template, context, content type, HTTP status, and charset.  
template  A backend-dependent template object (such as those returned by get_template()), the name of a template, or a list of template names. 
context  A dict of values to add to the template context. By default, this is an empty dictionary. 
content_type  The value included in the HTTP Content-Type header, including the MIME type specification and the character set encoding. If content_type is specified, then its value is used. Otherwise, 'text/html' is used. 
status  The HTTP status code for the response. 
charset  The charset in which the response will be encoded. If not given it will be extracted from content_type, and if that is unsuccessful, the DEFAULT_CHARSET setting will be used. 
using  The NAME of a template engine to use for loading the template. 
headers  A dict of HTTP headers to add to the response.   Changed in Django 3.2: The headers parameter was added.
SimpleTemplateResponse.add_post_render_callback()  
Add a callback that will be invoked after rendering has taken place. This hook can be used to defer certain processing operations (such as caching) until after rendering has occurred. If the SimpleTemplateResponse has already been rendered, the callback will be invoked immediately. When called, callbacks will be passed a single argument – the rendered SimpleTemplateResponse instance. If the callback returns a value that is not None, this will be used as the response instead of the original response object (and will be passed to the next post rendering callback etc.)
SimpleTemplateResponse.context_data  
The context data to be used when rendering the template. It must be a dict. Example: {'foo': 123}
SimpleTemplateResponse.is_rendered  
A boolean indicating whether the response content has been rendered.
SimpleTemplateResponse.render()  
Sets response.content to the result obtained by SimpleTemplateResponse.rendered_content, runs all post-rendering callbacks, and returns the resulting response object. render() will only have an effect the first time it is called. On subsequent calls, it will return the result obtained from the first call.
SimpleTemplateResponse.rendered_content  
The current rendered value of the response content, using the current template and context data.
SimpleTemplateResponse.resolve_context(context)  
Preprocesses context data that will be used for rendering a template. Accepts a dict of context data. By default, returns the same dict. Override this method in order to customize the context.
SimpleTemplateResponse.resolve_template(template)  
Resolves the template instance to use for rendering. Accepts a backend-dependent template object (such as those returned by get_template()), the name of a template, or a list of template names. Returns the backend-dependent template object instance to be rendered. Override this method in order to customize template loading.
SimpleTemplateResponse.template_name  
The name of the template to be rendered. Accepts a backend-dependent template object (such as those returned by get_template()), the name of a template, or a list of template names. Example: ['foo.html', 'path/to/bar.html']
class TemplateResponse  
TemplateResponse is a subclass of SimpleTemplateResponse that knows about the current HttpRequest.
TemplateResponse.__init__(request, template, context=None, content_type=None, status=None, charset=None, using=None, headers=None)  
Instantiates a TemplateResponse object with the given request, template, context, content type, HTTP status, and charset.  
request  An HttpRequest instance. 
template  A backend-dependent template object (such as those returned by get_template()), the name of a template, or a list of template names. 
context  A dict of values to add to the template context. By default, this is an empty dictionary. 
content_type  The value included in the HTTP Content-Type header, including the MIME type specification and the character set encoding. If content_type is specified, then its value is used. Otherwise, 'text/html' is used. 
status  The HTTP status code for the response. 
charset  The charset in which the response will be encoded. If not given it will be extracted from content_type, and if that is unsuccessful, the DEFAULT_CHARSET setting will be used. 
using  The NAME of a template engine to use for loading the template. 
headers  A dict of HTTP headers to add to the response.   Changed in Django 3.2: The headers parameter was added.
class Template  
This class lives at django.template.Template. The constructor takes one argument — the raw template code: from django.template import Template

template = Template("My name is {{ my_name }}.")
Template.render(context)  
Call the Template object’s render() method with a Context to “fill” the template: >>> from django.template import Context, Template
>>> template = Template("My name is {{ my_name }}.")

>>> context = Context({"my_name": "Adrian"})
>>> template.render(context)
"My name is Adrian."

>>> context = Context({"my_name": "Dolores"})
>>> template.render(context)
"My name is Dolores."
Templates Django’s template engine provides a powerful mini-language for defining the user-facing layer of your application, encouraging a clean separation of application and presentation logic. Templates can be maintained by anyone with an understanding of HTML; no knowledge of Python is required. For introductory material, see Templates topic guide.  
The Django template language Templates Variables Filters Tags Comments Template inheritance Automatic HTML escaping Accessing method calls Custom tag and filter libraries   
Built-in template tags and filters Built-in tag reference Built-in filter reference Internationalization tags and filters Other tags and filters libraries   
The Django template language: for Python programmers Overview Configuring an engine Loading a template Rendering a context Playing with Context objects Loading templates Custom loaders Template origin     See also For information on writing your own custom tags and filters, see How to create custom template tags and filters. To learn how to override templates in other Django applications, see How to override templates.
Client.cookies  
A Python SimpleCookie object, containing the current values of all the client cookies. See the documentation of the http.cookies module for more.
delete(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra)  
Makes a DELETE request on the provided path and returns a Response object. Useful for testing RESTful interfaces. When data is provided, it is used as the request body, and a Content-Type header is set to content_type. The follow, secure and extra arguments act the same as for Client.get().
force_login(user, backend=None)  
If your site uses Django’s authentication system, you can use the force_login() method to simulate the effect of a user logging into the site. Use this method instead of login() when a test requires a user be logged in and the details of how a user logged in aren’t important. Unlike login(), this method skips the authentication and verification steps: inactive users (is_active=False) are permitted to login and the user’s credentials don’t need to be provided. The user will have its backend attribute set to the value of the backend argument (which should be a dotted Python path string), or to settings.AUTHENTICATION_BACKENDS[0] if a value isn’t provided. The authenticate() function called by login() normally annotates the user like this. This method is faster than login() since the expensive password hashing algorithms are bypassed. Also, you can speed up login() by using a weaker hasher while testing.
get(path, data=None, follow=False, secure=False, **extra)  
Makes a GET request on the provided path and returns a Response object, which is documented below. The key-value pairs in the data dictionary are used to create a GET data payload. For example: >>> c = Client()
>>> c.get('/customers/details/', {'name': 'fred', 'age': 7})
 …will result in the evaluation of a GET request equivalent to: /customers/details/?name=fred&age=7
 The extra keyword arguments parameter can be used to specify headers to be sent in the request. For example: >>> c = Client()
>>> c.get('/customers/details/', {'name': 'fred', 'age': 7},
...       HTTP_ACCEPT='application/json')
 …will send the HTTP header HTTP_ACCEPT to the details view, which is a good way to test code paths that use the django.http.HttpRequest.accepts() method.  CGI specification The headers sent via **extra should follow CGI specification. For example, emulating a different “Host” header as sent in the HTTP request from the browser to the server should be passed as HTTP_HOST.  If you already have the GET arguments in URL-encoded form, you can use that encoding instead of using the data argument. For example, the previous GET request could also be posed as: >>> c = Client()
>>> c.get('/customers/details/?name=fred&age=7')
 If you provide a URL with both an encoded GET data and a data argument, the data argument will take precedence. If you set follow to True the client will follow any redirects and a redirect_chain attribute will be set in the response object containing tuples of the intermediate urls and status codes. If you had a URL /redirect_me/ that redirected to /next/, that redirected to /final/, this is what you’d see: >>> response = c.get('/redirect_me/', follow=True)
>>> response.redirect_chain
[('http://testserver/next/', 302), ('http://testserver/final/', 302)]
 If you set secure to True the client will emulate an HTTPS request.
head(path, data=None, follow=False, secure=False, **extra)  
Makes a HEAD request on the provided path and returns a Response object. This method works just like Client.get(), including the follow, secure and extra arguments, except it does not return a message body.
login(**credentials)  
If your site uses Django’s authentication system and you deal with logging in users, you can use the test client’s login() method to simulate the effect of a user logging into the site. After you call this method, the test client will have all the cookies and session data required to pass any login-based tests that may form part of a view. The format of the credentials argument depends on which authentication backend you’re using (which is configured by your AUTHENTICATION_BACKENDS setting). If you’re using the standard authentication backend provided by Django (ModelBackend), credentials should be the user’s username and password, provided as keyword arguments: >>> c = Client()
>>> c.login(username='fred', password='secret')

# Now you can access a view that's only available to logged-in users.
 If you’re using a different authentication backend, this method may require different credentials. It requires whichever credentials are required by your backend’s authenticate() method. login() returns True if it the credentials were accepted and login was successful. Finally, you’ll need to remember to create user accounts before you can use this method. As we explained above, the test runner is executed using a test database, which contains no users by default. As a result, user accounts that are valid on your production site will not work under test conditions. You’ll need to create users as part of the test suite – either manually (using the Django model API) or with a test fixture. Remember that if you want your test user to have a password, you can’t set the user’s password by setting the password attribute directly – you must use the set_password() function to store a correctly hashed password. Alternatively, you can use the create_user() helper method to create a new user with a correctly hashed password.