neulab/docprompting-conala huggingface dataset:
class AccessMixin  
 
login_url  
Default return value for get_login_url(). Defaults to None in which case get_login_url() falls back to settings.LOGIN_URL. 
  
permission_denied_message  
Default return value for get_permission_denied_message(). Defaults to an empty string. 
  
redirect_field_name  
Default return value for get_redirect_field_name(). Defaults to "next". 
  
raise_exception  
If this attribute is set to True, a PermissionDenied exception is raised when the conditions are not met. When False (the default), anonymous users are redirected to the login page. 
  
get_login_url()  
Returns the URL that users who don’t pass the test will be redirected to. Returns login_url if set, or settings.LOGIN_URL otherwise. 
  
get_permission_denied_message()  
When raise_exception is True, this method can be used to control the error message passed to the error handler for display to the user. Returns the permission_denied_message attribute by default. 
  
get_redirect_field_name()  
Returns the name of the query parameter that will contain the URL the user should be redirected to after a successful login. If you set this to None, a query parameter won’t be added. Returns the redirect_field_name attribute by default. 
  
handle_no_permission()  
Depending on the value of raise_exception, the method either raises a PermissionDenied exception or redirects the user to the login_url, optionally including the redirect_field_name if it is set.
get_login_url()  
Returns the URL that users who don’t pass the test will be redirected to. Returns login_url if set, or settings.LOGIN_URL otherwise.
get_permission_denied_message()  
When raise_exception is True, this method can be used to control the error message passed to the error handler for display to the user. Returns the permission_denied_message attribute by default.
get_redirect_field_name()  
Returns the name of the query parameter that will contain the URL the user should be redirected to after a successful login. If you set this to None, a query parameter won’t be added. Returns the redirect_field_name attribute by default.
handle_no_permission()  
Depending on the value of raise_exception, the method either raises a PermissionDenied exception or redirects the user to the login_url, optionally including the redirect_field_name if it is set.
login_url  
Default return value for get_login_url(). Defaults to None in which case get_login_url() falls back to settings.LOGIN_URL.
permission_denied_message  
Default return value for get_permission_denied_message(). Defaults to an empty string.
raise_exception  
If this attribute is set to True, a PermissionDenied exception is raised when the conditions are not met. When False (the default), anonymous users are redirected to the login page.
redirect_field_name  
Default return value for get_redirect_field_name(). Defaults to "next".
class LoginRequiredMixin  
If a view is using this mixin, all requests by non-authenticated users will be redirected to the login page or shown an HTTP 403 Forbidden error, depending on the raise_exception parameter. You can set any of the parameters of AccessMixin to customize the handling of unauthorized users: from django.contrib.auth.mixins import LoginRequiredMixin

class MyView(LoginRequiredMixin, View):
    login_url = '/login/'
    redirect_field_name = 'redirect_to'
class PermissionRequiredMixin  
This mixin, just like the permission_required decorator, checks whether the user accessing a view has all given permissions. You should specify the permission (or an iterable of permissions) using the permission_required parameter: from django.contrib.auth.mixins import PermissionRequiredMixin

class MyView(PermissionRequiredMixin, View):
    permission_required = 'polls.add_choice'
    # Or multiple of permissions:
    permission_required = ('polls.view_choice', 'polls.change_choice')
 You can set any of the parameters of AccessMixin to customize the handling of unauthorized users. You may also override these methods:  
get_permission_required()  
Returns an iterable of permission names used by the mixin. Defaults to the permission_required attribute, converted to a tuple if necessary. 
  
has_permission()  
Returns a boolean denoting whether the current user has permission to execute the decorated view. By default, this returns the result of calling has_perms() with the list of permissions returned by get_permission_required().
get_permission_required()  
Returns an iterable of permission names used by the mixin. Defaults to the permission_required attribute, converted to a tuple if necessary.
has_permission()  
Returns a boolean denoting whether the current user has permission to execute the decorated view. By default, this returns the result of calling has_perms() with the list of permissions returned by get_permission_required().
class UserPassesTestMixin  
When using class-based views, you can use the UserPassesTestMixin to do this.  
test_func()  
You have to override the test_func() method of the class to provide the test that is performed. Furthermore, you can set any of the parameters of AccessMixin to customize the handling of unauthorized users: from django.contrib.auth.mixins import UserPassesTestMixin

class MyView(UserPassesTestMixin, View):

    def test_func(self):
        return self.request.user.email.endswith('@example.com')
 
  
get_test_func()  
You can also override the get_test_func() method to have the mixin use a differently named function for its checks (instead of test_func()). 
  Stacking UserPassesTestMixin Due to the way UserPassesTestMixin is implemented, you cannot stack them in your inheritance list. The following does NOT work: class TestMixin1(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.email.endswith('@example.com')

class TestMixin2(UserPassesTestMixin):
    def test_func(self):
        return self.request.user.username.startswith('django')

class MyView(TestMixin1, TestMixin2, View):
    ...
 If TestMixin1 would call super() and take that result into account, TestMixin1 wouldn’t work standalone anymore.
get_test_func()  
You can also override the get_test_func() method to have the mixin use a differently named function for its checks (instead of test_func()).
test_func()  
You have to override the test_func() method of the class to provide the test that is performed. Furthermore, you can set any of the parameters of AccessMixin to customize the handling of unauthorized users: from django.contrib.auth.mixins import UserPassesTestMixin

class MyView(UserPassesTestMixin, View):

    def test_func(self):
        return self.request.user.email.endswith('@example.com')
class models.AbstractBaseUser  
 
get_username()  
Returns the value of the field nominated by USERNAME_FIELD. 
  
clean()  
Normalizes the username by calling normalize_username(). If you override this method, be sure to call super() to retain the normalization. 
  
classmethod get_email_field_name()  
Returns the name of the email field specified by the EMAIL_FIELD attribute. Defaults to 'email' if EMAIL_FIELD isn’t specified. 
  
classmethod normalize_username(username)  
Applies NFKC Unicode normalization to usernames so that visually identical characters with different Unicode code points are considered identical. 
  
is_authenticated  
Read-only attribute which is always True (as opposed to AnonymousUser.is_authenticated which is always False). This is a way to tell if the user has been authenticated. This does not imply any permissions and doesn’t check if the user is active or has a valid session. Even though normally you will check this attribute on request.user to find out whether it has been populated by the AuthenticationMiddleware (representing the currently logged-in user), you should know this attribute is True for any User instance. 
  
is_anonymous  
Read-only attribute which is always False. This is a way of differentiating User and AnonymousUser objects. Generally, you should prefer using is_authenticated to this attribute. 
  
set_password(raw_password)  
Sets the user’s password to the given raw string, taking care of the password hashing. Doesn’t save the AbstractBaseUser object. When the raw_password is None, the password will be set to an unusable password, as if set_unusable_password() were used. 
  
check_password(raw_password)  
Returns True if the given raw string is the correct password for the user. (This takes care of the password hashing in making the comparison.) 
  
set_unusable_password()  
Marks the user as having no password set. This isn’t the same as having a blank string for a password. check_password() for this user will never return True. Doesn’t save the AbstractBaseUser object. You may need this if authentication for your application takes place against an existing external source such as an LDAP directory. 
  
has_usable_password()  
Returns False if set_unusable_password() has been called for this user. 
  
get_session_auth_hash()  
Returns an HMAC of the password field. Used for Session invalidation on password change.
check_password(raw_password)  
Returns True if the given raw string is the correct password for the user. (This takes care of the password hashing in making the comparison.)
clean()  
Normalizes the username by calling normalize_username(). If you override this method, be sure to call super() to retain the normalization.
get_session_auth_hash()  
Returns an HMAC of the password field. Used for Session invalidation on password change.
has_usable_password()  
Returns False if set_unusable_password() has been called for this user.
is_anonymous  
Read-only attribute which is always False. This is a way of differentiating User and AnonymousUser objects. Generally, you should prefer using is_authenticated to this attribute.
is_authenticated  
Read-only attribute which is always True (as opposed to AnonymousUser.is_authenticated which is always False). This is a way to tell if the user has been authenticated. This does not imply any permissions and doesn’t check if the user is active or has a valid session. Even though normally you will check this attribute on request.user to find out whether it has been populated by the AuthenticationMiddleware (representing the currently logged-in user), you should know this attribute is True for any User instance.
set_password(raw_password)  
Sets the user’s password to the given raw string, taking care of the password hashing. Doesn’t save the AbstractBaseUser object. When the raw_password is None, the password will be set to an unusable password, as if set_unusable_password() were used.
set_unusable_password()  
Marks the user as having no password set. This isn’t the same as having a blank string for a password. check_password() for this user will never return True. Doesn’t save the AbstractBaseUser object. You may need this if authentication for your application takes place against an existing external source such as an LDAP directory.
class models.AbstractUser  
 
clean()  
Normalizes the email by calling BaseUserManager.normalize_email(). If you override this method, be sure to call super() to retain the normalization.
clean()  
Normalizes the email by calling BaseUserManager.normalize_email(). If you override this method, be sure to call super() to retain the normalization.
class models.AnonymousUser  
django.contrib.auth.models.AnonymousUser is a class that implements the django.contrib.auth.models.User interface, with these differences:  
id is always None. 
username is always the empty string. 
get_username() always returns the empty string. 
is_anonymous is True instead of False. 
is_authenticated is False instead of True. 
is_staff and is_superuser are always False. 
is_active is always False. 
groups and user_permissions are always empty. 
set_password(), check_password(), save() and delete() raise NotImplementedError.
class models.BaseUserManager  
 
classmethod normalize_email(email)  
Normalizes email addresses by lowercasing the domain portion of the email address. 
  
get_by_natural_key(username)  
Retrieves a user instance using the contents of the field nominated by USERNAME_FIELD. 
  
make_random_password(length=10, allowed_chars='abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789')  
Returns a random password with the given length and given string of allowed characters. Note that the default value of allowed_chars doesn’t contain letters that can cause user confusion, including:  
i, l, I, and 1 (lowercase letter i, lowercase letter L, uppercase letter i, and the number one) 
o, O, and 0 (lowercase letter o, uppercase letter o, and zero)
get_by_natural_key(username)  
Retrieves a user instance using the contents of the field nominated by USERNAME_FIELD.
make_random_password(length=10, allowed_chars='abcdefghjkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789')  
Returns a random password with the given length and given string of allowed characters. Note that the default value of allowed_chars doesn’t contain letters that can cause user confusion, including:  
i, l, I, and 1 (lowercase letter i, lowercase letter L, uppercase letter i, and the number one) 
o, O, and 0 (lowercase letter o, uppercase letter o, and zero)
class models.CustomUser  
 
USERNAME_FIELD  
A string describing the name of the field on the user model that is used as the unique identifier. This will usually be a username of some kind, but it can also be an email address, or any other unique identifier. The field must be unique (i.e., have unique=True set in its definition), unless you use a custom authentication backend that can support non-unique usernames. In the following example, the field identifier is used as the identifying field: class MyUser(AbstractBaseUser):
    identifier = models.CharField(max_length=40, unique=True)
    ...
    USERNAME_FIELD = 'identifier'
 
  
EMAIL_FIELD  
A string describing the name of the email field on the User model. This value is returned by get_email_field_name(). 
  
REQUIRED_FIELDS  
A list of the field names that will be prompted for when creating a user via the createsuperuser management command. The user will be prompted to supply a value for each of these fields. It must include any field for which blank is False or undefined and may include additional fields you want prompted for when a user is created interactively. REQUIRED_FIELDS has no effect in other parts of Django, like creating a user in the admin. For example, here is the partial definition for a user model that defines two required fields - a date of birth and height: class MyUser(AbstractBaseUser):
    ...
    date_of_birth = models.DateField()
    height = models.FloatField()
    ...
    REQUIRED_FIELDS = ['date_of_birth', 'height']
  Note REQUIRED_FIELDS must contain all required fields on your user model, but should not contain the USERNAME_FIELD or password as these fields will always be prompted for.  
  
is_active  
A boolean attribute that indicates whether the user is considered “active”. This attribute is provided as an attribute on AbstractBaseUser defaulting to True. How you choose to implement it will depend on the details of your chosen auth backends. See the documentation of the is_active attribute on the built-in
user model for details. 
  
get_full_name()  
Optional. A longer formal identifier for the user such as their full name. If implemented, this appears alongside the username in an object’s history in django.contrib.admin. 
  
get_short_name()  
Optional. A short, informal identifier for the user such as their first name. If implemented, this replaces the username in the greeting to the user in the header of django.contrib.admin. 
  Importing AbstractBaseUser AbstractBaseUser and BaseUserManager are importable from django.contrib.auth.base_user so that they can be imported without including django.contrib.auth in INSTALLED_APPS.
EMAIL_FIELD  
A string describing the name of the email field on the User model. This value is returned by get_email_field_name().
get_full_name()  
Optional. A longer formal identifier for the user such as their full name. If implemented, this appears alongside the username in an object’s history in django.contrib.admin.
get_short_name()  
Optional. A short, informal identifier for the user such as their first name. If implemented, this replaces the username in the greeting to the user in the header of django.contrib.admin.
is_active  
A boolean attribute that indicates whether the user is considered “active”. This attribute is provided as an attribute on AbstractBaseUser defaulting to True. How you choose to implement it will depend on the details of your chosen auth backends. See the documentation of the is_active attribute on the built-in
user model for details.
REQUIRED_FIELDS  
A list of the field names that will be prompted for when creating a user via the createsuperuser management command. The user will be prompted to supply a value for each of these fields. It must include any field for which blank is False or undefined and may include additional fields you want prompted for when a user is created interactively. REQUIRED_FIELDS has no effect in other parts of Django, like creating a user in the admin. For example, here is the partial definition for a user model that defines two required fields - a date of birth and height: class MyUser(AbstractBaseUser):
    ...
    date_of_birth = models.DateField()
    height = models.FloatField()
    ...
    REQUIRED_FIELDS = ['date_of_birth', 'height']
  Note REQUIRED_FIELDS must contain all required fields on your user model, but should not contain the USERNAME_FIELD or password as these fields will always be prompted for.
USERNAME_FIELD  
A string describing the name of the field on the user model that is used as the unique identifier. This will usually be a username of some kind, but it can also be an email address, or any other unique identifier. The field must be unique (i.e., have unique=True set in its definition), unless you use a custom authentication backend that can support non-unique usernames. In the following example, the field identifier is used as the identifying field: class MyUser(AbstractBaseUser):
    identifier = models.CharField(max_length=40, unique=True)
    ...
    USERNAME_FIELD = 'identifier'
class models.CustomUserManager  
 
create_user(username_field, password=None, **other_fields)  
The prototype of create_user() should accept the username field, plus all required fields as arguments. For example, if your user model uses email as the username field, and has date_of_birth as a required field, then create_user should be defined as: def create_user(self, email, date_of_birth, password=None):
    # create user here
    ...
 
  
create_superuser(username_field, password=None, **other_fields)  
The prototype of create_superuser() should accept the username field, plus all required fields as arguments. For example, if your user model uses email as the username field, and has date_of_birth as a required field, then create_superuser should be defined as: def create_superuser(self, email, date_of_birth, password=None):
    # create superuser here
    ...
create_superuser(username_field, password=None, **other_fields)  
The prototype of create_superuser() should accept the username field, plus all required fields as arguments. For example, if your user model uses email as the username field, and has date_of_birth as a required field, then create_superuser should be defined as: def create_superuser(self, email, date_of_birth, password=None):
    # create superuser here
    ...
create_user(username_field, password=None, **other_fields)  
The prototype of create_user() should accept the username field, plus all required fields as arguments. For example, if your user model uses email as the username field, and has date_of_birth as a required field, then create_user should be defined as: def create_user(self, email, date_of_birth, password=None):
    # create user here
    ...
name  
Required. 150 characters or fewer. Any characters are permitted. Example: 'Awesome Users'.
permissions  
Many-to-many field to Permission: group.permissions.set([permission_list])
group.permissions.add(permission, permission, ...)
group.permissions.remove(permission, permission, ...)
group.permissions.clear()
codename  
Required. 100 characters or fewer. Example: 'can_vote'.
content_type  
Required. A reference to the django_content_type database table, which contains a record for each installed model.
class models.PermissionsMixin  
 
is_superuser  
Boolean. Designates that this user has all permissions without explicitly assigning them. 
  
get_user_permissions(obj=None)  
Returns a set of permission strings that the user has directly. If obj is passed in, only returns the user permissions for this specific object. 
  
get_group_permissions(obj=None)  
Returns a set of permission strings that the user has, through their groups. If obj is passed in, only returns the group permissions for this specific object. 
  
get_all_permissions(obj=None)  
Returns a set of permission strings that the user has, both through group and user permissions. If obj is passed in, only returns the permissions for this specific object. 
  
has_perm(perm, obj=None)  
Returns True if the user has the specified permission, where perm is in the format "<app label>.<permission codename>" (see permissions). If User.is_active and is_superuser are both True, this method always returns True. If obj is passed in, this method won’t check for a permission for the model, but for this specific object. 
  
has_perms(perm_list, obj=None)  
Returns True if the user has each of the specified permissions, where each perm is in the format "<app label>.<permission codename>". If User.is_active and is_superuser are both True, this method always returns True. If obj is passed in, this method won’t check for permissions for the model, but for the specific object. 
  
has_module_perms(package_name)  
Returns True if the user has any permissions in the given package (the Django app label). If User.is_active and is_superuser are both True, this method always returns True.
get_all_permissions(obj=None)  
Returns a set of permission strings that the user has, both through group and user permissions. If obj is passed in, only returns the permissions for this specific object.
get_group_permissions(obj=None)  
Returns a set of permission strings that the user has, through their groups. If obj is passed in, only returns the group permissions for this specific object.
get_user_permissions(obj=None)  
Returns a set of permission strings that the user has directly. If obj is passed in, only returns the user permissions for this specific object.
has_module_perms(package_name)  
Returns True if the user has any permissions in the given package (the Django app label). If User.is_active and is_superuser are both True, this method always returns True.
has_perm(perm, obj=None)  
Returns True if the user has the specified permission, where perm is in the format "<app label>.<permission codename>" (see permissions). If User.is_active and is_superuser are both True, this method always returns True. If obj is passed in, this method won’t check for a permission for the model, but for this specific object.
has_perms(perm_list, obj=None)  
Returns True if the user has each of the specified permissions, where each perm is in the format "<app label>.<permission codename>". If User.is_active and is_superuser are both True, this method always returns True. If obj is passed in, this method won’t check for permissions for the model, but for the specific object.
is_superuser  
Boolean. Designates that this user has all permissions without explicitly assigning them.
date_joined  
A datetime designating when the account was created. Is set to the current date/time by default when the account is created.
email_user(subject, message, from_email=None, **kwargs)  
Sends an email to the user. If from_email is None, Django uses the DEFAULT_FROM_EMAIL. Any **kwargs are passed to the underlying send_mail() call.
get_full_name()  
Returns the first_name plus the last_name, with a space in between.
get_username()  
Returns the username for the user. Since the User model can be swapped out, you should use this method instead of referencing the username attribute directly.