oioioi.base.fields

Module Contents

Classes

DottedNameField	A CharField designed to store dotted names of Python classes.
EnumRegistry
EnumField	A CharField designed to store a value from an extensible set.
PhoneNumberField	A CharField designed to store phone numbers.
PostalCodeField	A CharField designed to store postal codes.

class oioioi.base.fields.DottedNameField(superclass, *args, **kwargs)

Bases: django.db.models.CharField

A CharField designed to store dotted names of Python classes.

The mandatory argument superclass should be the class, which subclasses can be stored in such fields.

Possible choices are automatically provided to Django, if the superclass has an attribute subclasses listing possible subclasses. :cls:`oioioi.base.utils.RegisteredSubclassesBase` may be used to automatically build such an attribute.

Before looking up subclasses, modules with names specified in the modules_with_subclasses class attribute of superclass are loaded from all applications registered with Django.

Subclasses may define ``description``s, which will be shown to the users in auto-generated forms instead of dotted names.

description

choices

get_choices(include_blank=True, blank_choice=BLANK_CHOICE_DASH, limit_choices_to=None)

Copied from Field and replaced self.choices with generate_choices to avoid circular dependency.

_get_choices()

validate(value, model_instance)

Validate value and raise ValidationError if necessary. Subclasses should override this to provide validation logic.

_get_superclass()

_generate_choices()

to_python(value)

Convert the input value into the expected Python data type, raising django.core.exceptions.ValidationError if the data can’t be converted. Return the converted value. Subclasses should override this.

deconstruct()

Return enough information to recreate the field as a 4-tuple:

• The name of the field on the model, if contribute_to_class() has been run.

• The import path of the field, including the class, e.g. django.db.models.IntegerField. This should be the most portable version, so less specific may be better.

• A list of positional arguments.

• A dict of keyword arguments.

Note that the positional or keyword arguments must contain values of the following types (including inner values of collection types):

• None, bool, str, int, float, complex, set, frozenset, list, tuple, dict

• UUID

• datetime.datetime (naive), datetime.date

• top-level classes, top-level functions - will be referenced by their full import path

• Storage instances - these have their own deconstruct() method

This is because the values here must be serialized into a text format (possibly new Python code, possibly JSON) and these are the only types with encoding handlers defined.

There’s no need to return the exact way the field was instantiated this time, just ensure that the resulting field is the same - prefer keyword arguments over positional ones, and omit parameters with their default values.

class oioioi.base.fields.EnumRegistry(max_length=64, entries=None)

Bases: object

__iter__()

__getitem__(key)

register(value, description)

get(value, fallback)

Return description for a given value, or fallback if value not in registry

class oioioi.base.fields.EnumField(registry=None, *args, **kwargs)

Bases: django.db.models.CharField

A CharField designed to store a value from an extensible set.

The set of possible values is stored in an :cls:`EnumRegistry`, which must be passed to the constructor.

Other apps may then extend the set of available choices by calling EnumRegistry.register(). The list of choices is populated the first time it is needed, therefore other application should probably register their values early during initialization, preferably in their models.py.

property choices

description

_generate_choices()

deconstruct()

Return enough information to recreate the field as a 4-tuple:

• The name of the field on the model, if contribute_to_class() has been run.

• The import path of the field, including the class, e.g. django.db.models.IntegerField. This should be the most portable version, so less specific may be better.

• A list of positional arguments.

• A dict of keyword arguments.

Note that the positional or keyword arguments must contain values of the following types (including inner values of collection types):

• None, bool, str, int, float, complex, set, frozenset, list, tuple, dict

• UUID

• datetime.datetime (naive), datetime.date

• top-level classes, top-level functions - will be referenced by their full import path

• Storage instances - these have their own deconstruct() method

This is because the values here must be serialized into a text format (possibly new Python code, possibly JSON) and these are the only types with encoding handlers defined.

There’s no need to return the exact way the field was instantiated this time, just ensure that the resulting field is the same - prefer keyword arguments over positional ones, and omit parameters with their default values.

class oioioi.base.fields.PhoneNumberField(*args, **kwargs)

Bases: django.db.models.CharField

A CharField designed to store phone numbers.

deconstruct()

Return enough information to recreate the field as a 4-tuple:

• The name of the field on the model, if contribute_to_class() has been run.

• The import path of the field, including the class, e.g. django.db.models.IntegerField. This should be the most portable version, so less specific may be better.

• A list of positional arguments.

• A dict of keyword arguments.

Note that the positional or keyword arguments must contain values of the following types (including inner values of collection types):

• None, bool, str, int, float, complex, set, frozenset, list, tuple, dict

• UUID

• datetime.datetime (naive), datetime.date

• top-level classes, top-level functions - will be referenced by their full import path

• Storage instances - these have their own deconstruct() method

This is because the values here must be serialized into a text format (possibly new Python code, possibly JSON) and these are the only types with encoding handlers defined.

There’s no need to return the exact way the field was instantiated this time, just ensure that the resulting field is the same - prefer keyword arguments over positional ones, and omit parameters with their default values.

class oioioi.base.fields.PostalCodeField(*args, **kwargs)

Bases: django.db.models.CharField

A CharField designed to store postal codes.

deconstruct()

Return enough information to recreate the field as a 4-tuple:

• The name of the field on the model, if contribute_to_class() has been run.

• The import path of the field, including the class, e.g. django.db.models.IntegerField. This should be the most portable version, so less specific may be better.

• A list of positional arguments.

• A dict of keyword arguments.

Note that the positional or keyword arguments must contain values of the following types (including inner values of collection types):

• None, bool, str, int, float, complex, set, frozenset, list, tuple, dict

• UUID

• datetime.datetime (naive), datetime.date

• top-level classes, top-level functions - will be referenced by their full import path

• Storage instances - these have their own deconstruct() method

This is because the values here must be serialized into a text format (possibly new Python code, possibly JSON) and these are the only types with encoding handlers defined.

There’s no need to return the exact way the field was instantiated this time, just ensure that the resulting field is the same - prefer keyword arguments over positional ones, and omit parameters with their default values.