J'aurais besoins de votre aide pour un exercice, celà fait un petit moment que je suis bloqué, je vous en remercie d'avance !
Voici l'énoncé :
Ce que j'ai fais :
jetons = int(input())
for i in range (jetons):
absi = int(input())
ordo = int(input())
if absi>=0 and absi<=10 and ordo>=0 and ordo>=55 and ordo<=70:
print("Dans une zone jaune")
elif absi >=0 and absi <=90 and ordo >=0 and ordo<10:
print("Dans une zone jaune")
elif absi>=85 and absi <=90 and ordo>=0 and ordo<=90:
print("Dans une zone jaune")
elif absi>=25 and absi <=50 and ordo>=20 and ordo<=45:
print("Dans une zone jaune")
elif absi>=10 and absi<=15 and ordo>=55 and ordo<=60:
print("Dans une zone jaune")
elif absi>=0 and absi <=90 and ordo>=55 and ordo<=60:
print("Dans une zone jaune")
elif absi>=45 and absi<=60 and ordo>=55 and ordo<=70:
print("Dans une zone jaune")
elif absi>=15 and absi <45 and ordo>=60 and ordo <=90:
print("Dans une zone rouge")
elif absi>=60 and absi<=85 and ordo>60 and ordo <=90:
print("Dans une zone rouge")
elif absi>=10 and absi<=85 and ordo>=10 and ordo<=20:
print("Dans une zone bleue")
elif absi>=10 and absi<=25 and ordo>=10 and ordo<=55:
print("Dans une zone bleue")
elif absi>=10 and absi<=85 and ordo>=45 and ordo<=55:
print("Dans une zone bleue")
elif absi>=50 and absi<=85 and ordo>=10 and ordo<=55:
print("Dans une zone bleue")
else:
print ("En dehors de la feuille")
Le résultat :
Je vous remercie grandement d'avance pour les personnes qui m'aiderons !
La première condition a l'air d'avoir un problème, j'ai pas vérifié mais je pense qu'avec ça tu exclus le rectangle 0-10 en abscisse, 0-55 en ordonnée.
Pour commencer, ton programme est difficilement maintenable, (condifition a ralonge, trop de cas) et difficile a lire, il faudrais : (1) définir une fonction de test dans un rectangle, (2) tester par imbrication avec une fonction qui retourne le texte et (3) géré les inputs dans un "main"
la bonne approche est donc:
tester s'il la position est dans la feuille sinon exit "En dehors ..."
tester le rectangle bleu, puis tester le rectangle jaune interieur
tester les rectangles rouges
sinon exit "jaune"
Cela pourait par exemple ressembler a ceci :
#!/usr/bin/env python3
def isinside_rect(pos, rect):
upperleft = pos[0]>=rect[0] and pos[1]>=rect[1]
lowerright = pos[0]<=rect[2] and pos[1]<=rect[3]
return upperleft and lowerright
pass
def getAreaName(pos):
if not isinside_rect(pos,[0,0,90,70]):
return "En dehord de la feuille"
if isinside_rect(pos,[10,10,85,55]):
if isinside_rect(pos,[20,25,50,45]):
return "Dans une zone jaune"
return "Dans une zone bleu"
elif isinside_rect(pos,[15,60,45,70]):
return "Dans une zone rouge"
elif isinside_rect(pos,[60,60,85,70]):
return "Dans une zone rouge"
return "Dans une zone jaune"
pass
if __name__ == "__main__":
jetons = int(input())
for i in range (jetons):
absi = int(input())
ordo = int(input())
print(getAreaName([absi,ordo]))
pass
pass
c'est une convention, cela aide à voir les bloques et donc les erreurs éventuelles d'indentations qui pourraient être détectées plus facilement par l'interpréteur (mais pas toutes). De façon générale cela ajoute donc simplement de la propreté au code (à mon sens, venant du c,c++,..).
exemple :
def f():
for i in range(10):
i = i * 2
print(i)
pass
pass
pass
Convention ? De qui ? Ce n'est en tout cas pas une convention Python.
ça ajoute de la longueur au code et retire en lisibilité ! C'est d'ailleurs pour cela qu'on a inventé la PEP8 afin de donner au code final le maximum de lisibilité aux développeurs du langage.
D'ailleurs en C, C++ on est pas obligé d'indenter, mais c'est fortement conseillé.
Perso, un contexte sens guard de fin quand il y a plusieurs instructions, ça me pique les yeux, je ne critique pas pour au temps. Et je ne suis pas le seul a pensé comme cela, mais qu'importe ? d'ailleurs pep8 ne donne pas de restriction concernant "pass" (il préconise un double sauts de ligne, lisible ?) ... Et puis il existe beaucoup de convention de codage différent, chacun est libre de ses choix (bien qu'un processus de normalisation soit important) et de penser que marquer la fin d'un contexte apporte en lisibilité, comme cela existe dans bon nombre de langage (basic, ada, c++, java, ...). C'est donc tout à fait défendable et, de plus utiliser (rarement certe) dans certaine entreprise, repos, ... etc en python.
J'ai 14 ans de c++, merci pour la pseudo remarque sur l'indentation, d'ailleurs, ton code ne compile pas. Puisque tu as deux contexte différent. Tu aurais dû utiliser un bloque "{}" ou à défaut changer la fin de la première instruction ";" par une séquence ",". Tien justement c'est ce que mettait en exergue mon exemple, c'est tellement facile d'ajouter ou retirer une tabulation par inadvertance et donc changer de context, que utilisé "pass" permet d'ajouter une sémantique au code et une étape de "correction" par l'interpreteur.
Longueur du code ? Quelle horreur 5 lignes inutile, plus, des sauts de ligne vide, un code propre ne doit-il pas être aéré ? Bref des arguments on peut en sortir à la pelle. C'est peut-être bien de voir qu'il n'existe pas une convention unique ? Bref ce n'était pas le sujet initial, et c'est un débat éternel.
Ma contribution histoire de montrer l'utilisation des opérateurs de comparaisons en Python et un petit troll :
for _ in range(int(input())):
x, y = int(input()), int(input())
if 0 <= x < 90 and 0 <= y < 70:
if 10 <= x < 85 and 10 <= y < 55 and not (25 <= x < 50 and 20 <= y < 45):
print("Dans une zone bleu")
elif (15 <= x < 45 or 60 <= x < 85) and y >= 60:
print("Dans une zone rouge") # Bah !? il manque un espace...
else:
print("Dans une zone jaune") # ohlala, cette indentation alors !
else:
print("En dehors de la feuille")
Edit: L'indentation n'est pas une convention en Python, c'est une règle de syntaxe ! Elle remplace les accolades et autres instructions délimitant des blocs d'instruction et force une mise en page claire et lisible du code. Ajouter une instruction, dont le rôle est d'ailleurs tout autre, pour marquer la fin d'un bloc est au mieux une preuve d’incompréhension de ce principe, au pire une insulte à ce qui est l'un des fondamentaux du langage et notamment une des raisons qui en fond un outils d'apprentissage idéal !
J'ai 14 ans de c++, merci pour la pseudo remarque sur l'indentation, d'ailleurs, ton code ne compile pas.
Ouais j'en ai tout autant à mon actif en C, ce n'est pas le problème ici, évidemment que mon code compile, mais je vais pas t'abaisser à entrer le code entier pour que tu puisses tester
Tu en vois aucune de différence dans la compilation, car pas besoin d'accolade dans ce cas de figure.
#include <stdio.h>
int main(void){
int i;
for (i=0; i<10; i++)
i *= 2;
printf("%d\n", i);
return 0;
}
et le mauvais cas de figure,
#include <stdio.h>
int main(void){
int i;
for (i=0; i<10; i++)
i *= 2;
printf("%d\n", i);
return 0;
}
On voit bien l'expression d'un bloc même sans accolade en C grâce à l'indentation, alors que pourtant, on pourrait l'éviter en C, seulement on le conseille pour une certaine lisibilité. Après chacun ses goûts, mais je préfère le 1er code au 2ème...
Ah ah, j'imagine effectivement que je suis un hérétique pour les fanboys,
Cela dit, vous détournez un poil mes propos, il ne s'agit en rien de contester l'indentation comme règle syntaxique (ou conventionnel pour d'autres langages), non critiquable par ailleurs. Mais simplement, jouer sur la convention suivante (PEP8) "Surround top-level function and class definitions with two blank lines." n'est au sens de certain pas suffisent. Et puis "pass" n'est d'ailleurs qu'un placeholder. Mais je vois pas en quoi, marquer les fins de (certain) bloques change quoique ce soit à l'apprentissage, ou en lisibilité, bien au contraire. Et de toute façon, les conventions, ça n'empêche pas de faire du code illisible, moche, .... (Bien entendu on doit s'adapter au choix technique dans une équipe).
Gaia a écrit:
> Il faut être ouvert, rien est immuable.
Mais le coding-style est bien défini. Il n'est pas question de fanboys ou quoi que ce soit, juste que tu détournes l'usage d'un mot-clé pour en faire n'importe quoi.
En fait, ce n'est pas pour t’agresser ou faire le fanboy, mais je pense que c'est justement tes 14 ans de C++ qui fond que tu ne vois pas le réel bénéfice qu'apporte la PEP-8 et cette règle syntaxique à l'ensemble du langage et des ses utilisateurs.
Le fait qu'il n'y ai qu'un seul coding-style - il n'y en a qu'un seul et unique - renforce la compréhension du langage, de ses principes et l'adoption des bonnes pratiques.
Tout à fait, et les habitudes sont tenaces ! Pas de soucis, mais ce n'est peut-être pas nécessaire de décrié l'approche à ce point. C’était d'ailleurs plus un détail sémantique, rappeler les conventions de pep8 était largement suffisent. Mais bon je suis aussi une tête de mule
@cernunnos! Bonsoir, merci de ne pas déterrer d'ancien sujet résolu pour une nouvelle question, créer le votre en insérant votre code avec l'outil d'intégration de code soit le bouton code </>, pas d'image de code totalement inutilisable par copier coller pour tests éventuels.
Avant de poster un message, vérifiez la date du sujet dans lequel vous comptiez intervenir.
Si le dernier message sur le sujet date de plus de deux mois, mieux vaut ne pas répondre. En effet, le déterrage d'un sujet nuit au bon fonctionnement du forum, et l'informatique pouvant grandement changer en quelques mois il n'est donc que rarement pertinent de déterrer un vieux sujet.
Au lieu de déterrer un sujet il est préférable :
soit de contacter directement le membre voulu par messagerie privée en cliquant sur son pseudonyme pour accéder à sa page profil, puis sur le lien "Ecrire un message"
soit de créer un nouveau sujet décrivant votre propre contexte
ne pas répondre à un déterrage et le signaler à la modération
Blond, bouclé, toujours le sourire aux lèvres...
Blond, bouclé, toujours le sourire aux lèvres...
Bonne journée...
Blond, bouclé, toujours le sourire aux lèvres...
Bonne journée...
Bonne journée...
entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d'un code pythonique