How should a task-management app represent a task? Start with what the app must do: create, view, edit, delete, sort, and filter tasks. A task needs a title, description, urgency level, and status. Those needs guide the data model rather than the other way around. section 14.2.1
A data model represents application data and the operations that prepare or process it. In Python, a custom class can hold data in attributes and provide related operations through methods. Simpler models may only need a container that holds values clearly. section 14.2 section 3.3
Listing 3.5 Using built-in data models for data management
task_list = ['Laundry', 'Wash clothes', 3] #1
task_tuple = ('Laundry', 'Wash clothes', 3) #2
task_dict = {'title': 'Laundry', 'desc': 'Wash clothes', 'urgency': 3} #3
Compare three ways to store a task’s title, description, and urgency. The dictionary names each field; the list and tuple rely on item position. section 3.3.1
Choose a representation for the job:
- Use a list for an ordered collection that may change, such as the places a user has visited. A tuple is a candidate for a place’s fixed latitude and longitude. section 3.1.4
- For a small record, a named tuple can hold data with named attributes and little memory overhead. A plain tuple is immutable but makes readers retrieve fields by position or unpacking. section 3.3 section 3.3.1
- Use a custom class when the model also needs application-specific methods. Its attributes capture the data; its methods process it. section 8.0
A task as a class
A minimal class can give each field a name: class Task: def __init__(self, title, desc, urgency): self.title = title self.desc = desc self.urgency = urgency task = Task('Laundry', 'Wash clothes', 3) This version stores data; add methods when the application needs task-specific behavior. Revisit the fields as features develop—for example, the fuller task-management app also requires status. section 3.3.1 section 14.2.1
Keep models maintainable as the project grows. Review classes whose attributes and methods serve unrelated purposes; a UML diagram can reveal functional groups. Aim for small, loosely connected classes. Keep a substantial model in its own file and import it into the interface code, rather than burying it among web-app functions. section 9.5.1 section 9.5.4 section 14.4.8
