Python 11.8 : Evolutions and issues

Cette vidéo poursuit le projet pizza pour montrer comment les structures de données simples atteignent leurs limites quand le projet évolue. On souhaite désormais associer un prix à chaque pizza. Première approche : créer une seconde liste de prix en parallèle. Mais cette solution n'est ni élégante ni robuste, car les deux listes risquent de se désynchroniser et l'affichage simultané du nom et du prix devient compliqué.

Tuples imbriqués et leurs limites

Une approche plus propre consiste à remplacer la liste de noms par une liste de tuples, chaque tuple contenant nom et prix de la pizza :

pizzas = [
    ('4 fromages', 12.99),
    ('Margherita', 10.99),
    ('Pepperoni', 13.50)
]

# Accès aux données par indices imbriqués
print(pizzas[0][0])  # '4 fromages'
print(pizzas[0][1])  # 12.99

Cette solution synchronise les données mais introduit une syntaxe d'accès à deux niveaux (pizzas[0][0] pour le nom, pizzas[0][1] pour le prix). Le code devient moins lisible et plus fragile. Surtout, cette approche montre ses limites dès qu'on veut ajouter d'autres attributs :

  • Si on rajoute les ingrédients, l'indice devient pizzas[0][2]
  • Ajouter un attribut au début casserait tout le code existant
  • Pas d'auto-documentation : indices numériques peu parlants
  • Risque d'erreurs sur les positions à mémoriser

C'est exactement le problème que la programmation orientée objet vient résoudre. En définissant une classe Pizza avec des attributs nommés (nom, prix, ingrédients), on rend le code expressif, évolutif et maintenable. pizza.prix est infiniment plus clair que pizzas[0][1]. La prochaine section du cours abordera la POO et proposera une version 2 du projet pizza, beaucoup plus solide et extensible.

Summary

This lesson explores evolving a pizza project by adding pricing information and addresses the structural challenges that arise from managing multiple related data elements. The instructor demonstrates why separate lists and nested indices create synchronization problems, then shows how tuples can pair pizza names with prices—but highlights the scalability limitations of this approach when additional attributes need to be added. These practical issues motivate the need for object-oriented programming as a more robust solution.

Key points

  • Adding pricing to pizza objects requires reorganizing data structures beyond simple indexed lists
  • Separate lists for pizzas and prices cause synchronization problems and make simultaneous data retrieval difficult
  • Nested indices (e.g., [0][0] for pizza name, [0][1] for price) work but become error-prone as data complexity grows
  • Tuples group related values together, improving upon separate lists but still lack flexibility for future attributes
  • Adding more elements like ingredients requires modifying code throughout the program, demonstrating poor scalability
  • These limitations expose the need for object-oriented programming to handle complex, multi-attribute data structures

FAQ

Why are separate lists for pizzas and prices problematic?

Separate lists create synchronization issues—you must manually manage indices from two different arrays to retrieve matching values. This makes the code fragile and difficult to maintain when you need to correlate pizza names with their prices.

How do tuples improve the data structure?

Tuples group related data into single elements (e.g., [pizza_name, price]), eliminating the index mismatch problem. Instead of tracking two separate indices, each pizza carries its price directly within a single data unit.

Why doesn't the tuple approach scale well?

While tuples reduce synchronization issues, adding new attributes (like ingredients or allergen information) requires modifying code throughout the program. This rigidity demonstrates why object-oriented programming, which encapsulates all pizza attributes in reusable objects, is a better long-term solution.