Bonjour et Bonne ann=E9e =E0 tous.
Pour commencer l'ann=E9e, et comme l'hiver est d=E9j=E0 bien froid et risqu=
e
d'=EAtre long, je me suis mis =E0 la programmation objet (je vois les
sourires de mes interlocuteurs des threads pr=E9c=E9dents). J'ai d=E9velopp=
=E9
une petite appli de renommage de fichiers visible =E0 cette adresse :
et j'ai mis toute mon appli dans une m=EAme classe. Ce n'est peut-=EAtre
pas tr=E8s =E9l=E9gant.
Y-a-t-il une r=E8gle concernant l'architecture des programmes objet et
existe-t-il sur le web quelque chose qui en parle (si possible en
fran=E7ais) ? Je ne vois pas trop comment s=E9parer les diff=E9rentes
classes d'objet car tout est plus ou moins interd=E9pendant. Passant de
la programmation proc=E9durale =E0 la prog. objet je suis un peu perdu
pour organiser mon appli.
merci de vos conseils.
YLC
Bonjour et Bonne année à tous. Pour commencer l'année, et comme l'hiver est déjà bien froid et risque d'être long, je me suis mis à la programmation objet (je vois les sourires de mes interlocuteurs des threads précédents). J'ai développé une petite appli de renommage de fichiers visible à cette adresse :
et j'ai mis toute mon appli dans une même classe. Ce n'est peut-être pas très élégant.
Non, en effet.
Y-a-t-il une règle concernant l'architecture des programmes objet
Il y en a beaucoup, toutes plus ou moins discutables, et certaines pas tellement spécifiques à l'OO.
et existe-t-il sur le web quelque chose qui en parle (si possible en français) ? Je ne vois pas trop comment séparer les différentes classes d'objet car tout est plus ou moins interdépendant. Passant de la programmation procédurale à la prog. objet je suis un peu perdu pour organiser mon appli.
Python ne t'oblige en rien à utiliser la POO là où elle n'est pas nécessaire. Globalement, ton appli est composée de deux chose:
1/ une interface utilisateur 2/ le "moteur" - c'est à dire, toutes les fonctionnalités qui ne relèvent pas directement de l'interface utilisateur.
Pour le 1/, tu n'a guère d'autre choix qu'utiliser la POO puisque ton GUI toolkit (comme à peu près tous les GUI toolkits Python) est basé dessus.
Pour le 2/, ça n'a rien à faire dans le 1/, ça doit fonctionner indépendemment du 1/, et accessoirement ça ne nécessite pas forcément une approche objet (dans ton cas en particulier, quelques fonctions suffiraient).
Sinon et tout à fait hors-sujet, je me permet d'attirer ton attention sur - le formatage de chaines: s = "%s/%s" % ('toto', 'tata') print s - le module os.path - le module shutils
yveslc35@gmail.com a écrit :
Bonjour et Bonne année à tous.
Pour commencer l'année, et comme l'hiver est déjà bien froid et risque
d'être long, je me suis mis à la programmation objet (je vois les
sourires de mes interlocuteurs des threads précédents). J'ai développé
une petite appli de renommage de fichiers visible à cette adresse :
et j'ai mis toute mon appli dans une même classe. Ce n'est peut-être
pas très élégant.
Non, en effet.
Y-a-t-il une règle concernant l'architecture des programmes objet
Il y en a beaucoup, toutes plus ou moins discutables, et certaines pas
tellement spécifiques à l'OO.
et
existe-t-il sur le web quelque chose qui en parle (si possible en
français) ? Je ne vois pas trop comment séparer les différentes
classes d'objet car tout est plus ou moins interdépendant. Passant de
la programmation procédurale à la prog. objet je suis un peu perdu
pour organiser mon appli.
Python ne t'oblige en rien à utiliser la POO là où elle n'est pas
nécessaire. Globalement, ton appli est composée de deux chose:
1/ une interface utilisateur
2/ le "moteur" - c'est à dire, toutes les fonctionnalités qui ne
relèvent pas directement de l'interface utilisateur.
Pour le 1/, tu n'a guère d'autre choix qu'utiliser la POO puisque ton
GUI toolkit (comme à peu près tous les GUI toolkits Python) est basé dessus.
Pour le 2/, ça n'a rien à faire dans le 1/, ça doit fonctionner
indépendemment du 1/, et accessoirement ça ne nécessite pas forcément
une approche objet (dans ton cas en particulier, quelques fonctions
suffiraient).
Sinon et tout à fait hors-sujet, je me permet d'attirer ton attention sur
- le formatage de chaines:
s = "%s/%s" % ('toto', 'tata')
print s
- le module os.path
- le module shutils
Bonjour et Bonne année à tous. Pour commencer l'année, et comme l'hiver est déjà bien froid et risque d'être long, je me suis mis à la programmation objet (je vois les sourires de mes interlocuteurs des threads précédents). J'ai développé une petite appli de renommage de fichiers visible à cette adresse :
et j'ai mis toute mon appli dans une même classe. Ce n'est peut-être pas très élégant.
Non, en effet.
Y-a-t-il une règle concernant l'architecture des programmes objet
Il y en a beaucoup, toutes plus ou moins discutables, et certaines pas tellement spécifiques à l'OO.
et existe-t-il sur le web quelque chose qui en parle (si possible en français) ? Je ne vois pas trop comment séparer les différentes classes d'objet car tout est plus ou moins interdépendant. Passant de la programmation procédurale à la prog. objet je suis un peu perdu pour organiser mon appli.
Python ne t'oblige en rien à utiliser la POO là où elle n'est pas nécessaire. Globalement, ton appli est composée de deux chose:
1/ une interface utilisateur 2/ le "moteur" - c'est à dire, toutes les fonctionnalités qui ne relèvent pas directement de l'interface utilisateur.
Pour le 1/, tu n'a guère d'autre choix qu'utiliser la POO puisque ton GUI toolkit (comme à peu près tous les GUI toolkits Python) est basé dessus.
Pour le 2/, ça n'a rien à faire dans le 1/, ça doit fonctionner indépendemment du 1/, et accessoirement ça ne nécessite pas forcément une approche objet (dans ton cas en particulier, quelques fonctions suffiraient).
Sinon et tout à fait hors-sujet, je me permet d'attirer ton attention sur - le formatage de chaines: s = "%s/%s" % ('toto', 'tata') print s - le module os.path - le module shutils
hervest
yveslc35 a écrit le 02/01/2009 à 17h34 :
Bonjour et Bonne année à tous. Pour commencer l'année, et comme l'hiver est déjà bien froid et risqu= e d'être long, je me suis mis à la programmation objet (je vois les sourires de mes interlocuteurs des threads précédents). J'ai développ= é une petite appli de renommage de fichiers visible à cette adresse :
et j'ai mis toute mon appli dans une même classe. Ce n'est peut-être pas très élégant. Y-a-t-il une règle concernant l'architecture des programmes objet et existe-t-il sur le web quelque chose qui en parle (si possible en français) ? Je ne vois pas trop comment séparer les différentes classes d'objet car tout est plus ou moins interdépendant. Passant de la programmation procédurale à la prog. objet je suis un peu perdu pour organiser mon appli. merci de vos conseils. YLC
bonjour
voici le livre que je conseil à tous ceux qui veulent apprendre à programmer en python. C'est le même qui m'a aidé. Il te montrera comment penser comme un programmeur.
tu trouveras à la page 129 (chapitre 22) les réponses à tes questions sur les classes.
Bonne chance avec python objet
yveslc35 a écrit le 02/01/2009 à 17h34 :
Bonjour et Bonne ann=E9e =E0 tous.
Pour commencer l'ann=E9e, et comme l'hiver est d=E9j=E0 bien froid et risqu=
e
d'=EAtre long, je me suis mis =E0 la programmation objet (je vois les
sourires de mes interlocuteurs des threads pr=E9c=E9dents). J'ai d=E9velopp=
=E9
une petite appli de renommage de fichiers visible =E0 cette adresse :
et j'ai mis toute mon appli dans une m=EAme classe. Ce n'est peut-=EAtre
pas tr=E8s =E9l=E9gant.
Y-a-t-il une r=E8gle concernant l'architecture des programmes objet et
existe-t-il sur le web quelque chose qui en parle (si possible en
fran=E7ais) ? Je ne vois pas trop comment s=E9parer les diff=E9rentes
classes d'objet car tout est plus ou moins interd=E9pendant. Passant de
la programmation proc=E9durale =E0 la prog. objet je suis un peu perdu
pour organiser mon appli.
merci de vos conseils.
YLC
bonjour
voici le livre que je conseil à tous ceux qui veulent apprendre à programmer en python. C'est le même qui m'a aidé. Il te montrera comment penser comme un programmeur.
Bonjour et Bonne année à tous. Pour commencer l'année, et comme l'hiver est déjà bien froid et risqu= e d'être long, je me suis mis à la programmation objet (je vois les sourires de mes interlocuteurs des threads précédents). J'ai développ= é une petite appli de renommage de fichiers visible à cette adresse :
et j'ai mis toute mon appli dans une même classe. Ce n'est peut-être pas très élégant. Y-a-t-il une règle concernant l'architecture des programmes objet et existe-t-il sur le web quelque chose qui en parle (si possible en français) ? Je ne vois pas trop comment séparer les différentes classes d'objet car tout est plus ou moins interdépendant. Passant de la programmation procédurale à la prog. objet je suis un peu perdu pour organiser mon appli. merci de vos conseils. YLC
bonjour
voici le livre que je conseil à tous ceux qui veulent apprendre à programmer en python. C'est le même qui m'a aidé. Il te montrera comment penser comme un programmeur.
tu trouveras à la page 129 (chapitre 22) les réponses à tes questions sur les classes.
Bonne chance avec python objet
Pierre Maurette
, le 02/01/2009 a écrit :
Bonjour et Bonne année à tous. Pour commencer l'année, et comme l'hiver est déjà bien froid et risque d'être long, je me suis mis à la programmation objet (je vois les sourires de mes interlocuteurs des threads précédents). J'ai développé une petite appli de renommage de fichiers visible à cette adresse :
et j'ai mis toute mon appli dans une même classe. Ce n'est peut-être pas très élégant. Y-a-t-il une règle concernant l'architecture des programmes objet et existe-t-il sur le web quelque chose qui en parle (si possible en français) ? Je ne vois pas trop comment séparer les différentes classes d'objet car tout est plus ou moins interdépendant. Passant de la programmation procédurale à la prog. objet je suis un peu perdu pour organiser mon appli.
J'ai à peine regardé, c'est joli, plein de couleurs ;-) . Juste quelques suggestions, en commençant par les plus futiles:
-- Pensez à renommer votre .py en .pyw
-- Il est dommage de ne pas développer ce genre de programme en multiplateforme. En fait, c'est pratiquement automatique si on code "dans les règles de l'art", en utilisant le bon module là où il faut, comme os.path déjà signalé.
-- J'organise en général ce genre d'utilitaire de la façon suivante: - Un utilitaire en ligne de commande, renommeur.py. Voir le module standard optparse. Personnellement, j'aurais une classe sessionRenommage, qui contiendrait une liste de fichers, un répertoire cible, une série de paramètres de comportement et de renommage (tout ça, ça correspond en gros à votre interface), une méthode getFilenames qui renverrait les noms de fichiers modifiés, une méthode doIt qui utiliserait la précédente pour finaliser le renommage, etc. Il ne me semble pas nécessaire de séparer en deux fichiers cette partie d'une main qui parserait la ligne de commandes et utiliserait la classe sessionRenommage en quelques lignes. - Un wrapper Tkinter, renommeurtk.pyw. Vous pouvez ainsi utiliser votre travail de quatre façons: - En clicodrome Tkinter. - En console, en ligne de commandes. - A partir de n'importe quel programme ou script, python ou autre, par la ligne de commandes. - A partir d'un programme python, en important renommeur.py et en utilisant la classe sessionRenommage.
-- Pierre Maurette
yveslc35@gmail.com, le 02/01/2009 a écrit :
Bonjour et Bonne année à tous.
Pour commencer l'année, et comme l'hiver est déjà bien froid et risque
d'être long, je me suis mis à la programmation objet (je vois les
sourires de mes interlocuteurs des threads précédents). J'ai développé
une petite appli de renommage de fichiers visible à cette adresse :
et j'ai mis toute mon appli dans une même classe. Ce n'est peut-être
pas très élégant.
Y-a-t-il une règle concernant l'architecture des programmes objet et
existe-t-il sur le web quelque chose qui en parle (si possible en
français) ? Je ne vois pas trop comment séparer les différentes
classes d'objet car tout est plus ou moins interdépendant. Passant de
la programmation procédurale à la prog. objet je suis un peu perdu
pour organiser mon appli.
J'ai à peine regardé, c'est joli, plein de couleurs ;-) . Juste
quelques suggestions, en commençant par les plus futiles:
-- Pensez à renommer votre .py en .pyw
-- Il est dommage de ne pas développer ce genre de programme en
multiplateforme. En fait, c'est pratiquement automatique si on code
"dans les règles de l'art", en utilisant le bon module là où il faut,
comme os.path déjà signalé.
-- J'organise en général ce genre d'utilitaire de la façon suivante:
- Un utilitaire en ligne de commande, renommeur.py. Voir le module
standard optparse. Personnellement, j'aurais une classe
sessionRenommage, qui contiendrait une liste de fichers, un répertoire
cible, une série de paramètres de comportement et de renommage (tout
ça, ça correspond en gros à votre interface), une méthode getFilenames
qui renverrait les noms de fichiers modifiés, une méthode doIt qui
utiliserait la précédente pour finaliser le renommage, etc. Il ne me
semble pas nécessaire de séparer en deux fichiers cette partie d'une
main qui parserait la ligne de commandes et utiliserait la classe
sessionRenommage en quelques lignes.
- Un wrapper Tkinter, renommeurtk.pyw.
Vous pouvez ainsi utiliser votre travail de quatre façons:
- En clicodrome Tkinter.
- En console, en ligne de commandes.
- A partir de n'importe quel programme ou script, python ou autre, par
la ligne de commandes.
- A partir d'un programme python, en important renommeur.py et en
utilisant la classe sessionRenommage.
Bonjour et Bonne année à tous. Pour commencer l'année, et comme l'hiver est déjà bien froid et risque d'être long, je me suis mis à la programmation objet (je vois les sourires de mes interlocuteurs des threads précédents). J'ai développé une petite appli de renommage de fichiers visible à cette adresse :
et j'ai mis toute mon appli dans une même classe. Ce n'est peut-être pas très élégant. Y-a-t-il une règle concernant l'architecture des programmes objet et existe-t-il sur le web quelque chose qui en parle (si possible en français) ? Je ne vois pas trop comment séparer les différentes classes d'objet car tout est plus ou moins interdépendant. Passant de la programmation procédurale à la prog. objet je suis un peu perdu pour organiser mon appli.
J'ai à peine regardé, c'est joli, plein de couleurs ;-) . Juste quelques suggestions, en commençant par les plus futiles:
-- Pensez à renommer votre .py en .pyw
-- Il est dommage de ne pas développer ce genre de programme en multiplateforme. En fait, c'est pratiquement automatique si on code "dans les règles de l'art", en utilisant le bon module là où il faut, comme os.path déjà signalé.
-- J'organise en général ce genre d'utilitaire de la façon suivante: - Un utilitaire en ligne de commande, renommeur.py. Voir le module standard optparse. Personnellement, j'aurais une classe sessionRenommage, qui contiendrait une liste de fichers, un répertoire cible, une série de paramètres de comportement et de renommage (tout ça, ça correspond en gros à votre interface), une méthode getFilenames qui renverrait les noms de fichiers modifiés, une méthode doIt qui utiliserait la précédente pour finaliser le renommage, etc. Il ne me semble pas nécessaire de séparer en deux fichiers cette partie d'une main qui parserait la ligne de commandes et utiliserait la classe sessionRenommage en quelques lignes. - Un wrapper Tkinter, renommeurtk.pyw. Vous pouvez ainsi utiliser votre travail de quatre façons: - En clicodrome Tkinter. - En console, en ligne de commandes. - A partir de n'importe quel programme ou script, python ou autre, par la ligne de commandes. - A partir d'un programme python, en important renommeur.py et en utilisant la classe sessionRenommage.
-- Pierre Maurette
Méta-MCI \(MVP\)
Bonsoir !
Je vais jouer au petit BD(*) du vendredi... Plutôt que de "programme objet", il faudrait parler de "programme orienté objet".
@+
MCI
(*) J'espère que Bruno ne m'en voudra pas trop d'utiliser ses initiales comme synonyme de puriste...
Bonsoir !
Je vais jouer au petit BD(*) du vendredi...
Plutôt que de "programme objet", il faudrait parler de "programme
orienté objet".
@+
MCI
(*) J'espère que Bruno ne m'en voudra pas trop d'utiliser ses initiales
comme synonyme de puriste...
Je vais jouer au petit BD(*) du vendredi... Plutôt que de "programme objet", il faudrait parler de "programme orienté objet".
@+
MCI
(*) J'espère que Bruno ne m'en voudra pas trop d'utiliser ses initiales comme synonyme de puriste...
yveslc35
Bonjour, Que de réponses !.... merci à tous. Bruno attire mon attention sur : le module os.path et le module shutils. Pourquoi ? Aurais-je mal utilisé os.path ? Quant au module shutil, il fait la même chose que le rename utilisé, non ? Pierre dit que j'aurais du faire un prog multiplateformes. Mon programme utilise-t-il donc des fonctions spécifiques à Windows ? J'ai pourtant fait attention à ne pas utiliser des fonctions spécifiques. YLC
Bonjour,
Que de réponses !.... merci à tous.
Bruno attire mon attention sur : le module os.path et le module
shutils. Pourquoi ?
Aurais-je mal utilisé os.path ? Quant au module shutil, il fait la
même chose que le rename utilisé, non ?
Pierre dit que j'aurais du faire un prog multiplateformes. Mon
programme utilise-t-il donc des fonctions spécifiques à Windows ? J'ai
pourtant fait attention à ne pas utiliser des fonctions spécifiques.
YLC
Bonjour, Que de réponses !.... merci à tous. Bruno attire mon attention sur : le module os.path et le module shutils. Pourquoi ? Aurais-je mal utilisé os.path ? Quant au module shutil, il fait la même chose que le rename utilisé, non ? Pierre dit que j'aurais du faire un prog multiplateformes. Mon programme utilise-t-il donc des fonctions spécifiques à Windows ? J'ai pourtant fait attention à ne pas utiliser des fonctions spécifiques. YLC
Bruno Desthuilliers
Méta-MCI (MVP) a écrit :
Bonsoir !
Je vais jouer au petit BD(*) du vendredi...
(snip)
(*) J'espère que Bruno ne m'en voudra pas trop d'utiliser ses initiales comme synonyme de puriste...
Pas de problème, j'assume !-)
Méta-MCI (MVP) a écrit :
Bonsoir !
Je vais jouer au petit BD(*) du vendredi...
(snip)
(*) J'espère que Bruno ne m'en voudra pas trop d'utiliser ses initiales
comme synonyme de puriste...
(*) J'espère que Bruno ne m'en voudra pas trop d'utiliser ses initiales comme synonyme de puriste...
Pas de problème, j'assume !-)
Bruno Desthuilliers
a écrit :
Bonjour, Que de réponses !.... merci à tous. Bruno attire mon attention sur : le module os.path et le module shutils. Pourquoi ?
Heu... Parce que ça peut être utile ?-)
Aurais-je mal utilisé os.path ?
C'est surtout que tu n'utilises pas os.path.join()
Quant au module shutil, il fait la même chose que le rename utilisé, non ?
Concernant celui-ci, c'était juste à toutes fins utiles (puisque tu était dans des opération de fichier) - la bibliothèque standard de Python est vaste et il est courant, même après plusieurs années, de réinventer la roue (carrée de préférence) alors que tout le nécessaire existe déjà.
Pierre dit que j'aurais du faire un prog multiplateformes. Mon programme utilise-t-il donc des fonctions spécifiques à Windows ?
from winsound import * # windows-only dirinit=noudir="C:/" # windows-only nomlog=os.getcwd()+"renom.log" # separateur de chemin windows
HTH
yveslc35@gmail.com a écrit :
Bonjour,
Que de réponses !.... merci à tous.
Bruno attire mon attention sur : le module os.path et le module
shutils. Pourquoi ?
Heu... Parce que ça peut être utile ?-)
Aurais-je mal utilisé os.path ?
C'est surtout que tu n'utilises pas os.path.join()
Quant au module shutil, il fait la
même chose que le rename utilisé, non ?
Concernant celui-ci, c'était juste à toutes fins utiles (puisque tu
était dans des opération de fichier) - la bibliothèque standard de
Python est vaste et il est courant, même après plusieurs années, de
réinventer la roue (carrée de préférence) alors que tout le nécessaire
existe déjà.
Pierre dit que j'aurais du faire un prog multiplateformes. Mon
programme utilise-t-il donc des fonctions spécifiques à Windows ?
from winsound import * # windows-only
dirinit=noudir="C:/" # windows-only
nomlog=os.getcwd()+"\renom.log" # separateur de chemin windows
Bonjour, Que de réponses !.... merci à tous. Bruno attire mon attention sur : le module os.path et le module shutils. Pourquoi ?
Heu... Parce que ça peut être utile ?-)
Aurais-je mal utilisé os.path ?
C'est surtout que tu n'utilises pas os.path.join()
Quant au module shutil, il fait la même chose que le rename utilisé, non ?
Concernant celui-ci, c'était juste à toutes fins utiles (puisque tu était dans des opération de fichier) - la bibliothèque standard de Python est vaste et il est courant, même après plusieurs années, de réinventer la roue (carrée de préférence) alors que tout le nécessaire existe déjà.
Pierre dit que j'aurais du faire un prog multiplateformes. Mon programme utilise-t-il donc des fonctions spécifiques à Windows ?
from winsound import * # windows-only dirinit=noudir="C:/" # windows-only nomlog=os.getcwd()+"renom.log" # separateur de chemin windows
HTH
yveslc35
> > Pierre dit que j'aurais du faire un prog multiplateformes. Mon > programme utilise-t-il donc des fonctions spécifiques à Windows ?
from winsound import * # windows-only dirinit=noudir="C:/" # windows-only nomlog=os.getcwd()+"renom.log" # separateur de chemin windows
HTH
Bon ok, pour winsound je n'y avais pas pensé. Mais qu'aurais-tu utilisé à la place pour beeper en cas d'erreur ? Sinon les variables initialisée avec des valeurs propres à Windows peuvent facilement être initilisées par des valeurs propres à la plateforme d'utilisation. Ce qui compte, je pense que ce sont les fonctions utilisées qui doivent être portables. YLC
> > Pierre dit que j'aurais du faire un prog multiplateformes. Mon
> programme utilise-t-il donc des fonctions spécifiques à Windows ?
from winsound import * # windows-only
dirinit=noudir="C:/" # windows-only
nomlog=os.getcwd()+"\renom.log" # separateur de chemin windows
HTH
Bon ok, pour winsound je n'y avais pas pensé. Mais qu'aurais-tu
utilisé à la place pour beeper en cas d'erreur ?
Sinon les variables initialisée avec des valeurs propres à Windows
peuvent facilement être initilisées par des valeurs propres à la
plateforme d'utilisation. Ce qui compte, je pense que ce sont les
fonctions utilisées qui doivent être portables.
YLC
> > Pierre dit que j'aurais du faire un prog multiplateformes. Mon > programme utilise-t-il donc des fonctions spécifiques à Windows ?
from winsound import * # windows-only dirinit=noudir="C:/" # windows-only nomlog=os.getcwd()+"renom.log" # separateur de chemin windows
HTH
Bon ok, pour winsound je n'y avais pas pensé. Mais qu'aurais-tu utilisé à la place pour beeper en cas d'erreur ? Sinon les variables initialisée avec des valeurs propres à Windows peuvent facilement être initilisées par des valeurs propres à la plateforme d'utilisation. Ce qui compte, je pense que ce sont les fonctions utilisées qui doivent être portables. YLC
Bruno Desthuilliers
a écrit :
Pierre dit que j'aurais du faire un prog multiplateformes. Mon programme utilise-t-il donc des fonctions spécifiques à Windows ?
from winsound import * # windows-only dirinit=noudir="C:/" # windows-only nomlog=os.getcwd()+"renom.log" # separateur de chemin windows
HTH
Bon ok, pour winsound je n'y avais pas pensé. Mais qu'aurais-tu utilisé à la place pour beeper en cas d'erreur ?
Rien - les programmes qui bippent m'exaspèrent !-)
Mais bon, si tu y tiens vraiment, à toi de voir quelles solutions sont disponibles suivant les plateformes - en commençant par vérifier si ton GUI toolkit ne propose pas déjà cette fonctionnalité.
Sinon les variables initialisée avec des valeurs propres à Windows peuvent facilement être initilisées par des valeurs propres à la plateforme d'utilisation.
Alors ne t'en prives pas !-)
Ce qui compte, je pense que ce sont les fonctions utilisées qui doivent être portables.
Ce qui est un des intérêts de os.path.join()
yveslc35@gmail.com a écrit :
Pierre dit que j'aurais du faire un prog multiplateformes. Mon
programme utilise-t-il donc des fonctions spécifiques à Windows ?
from winsound import * # windows-only
dirinit=noudir="C:/" # windows-only
nomlog=os.getcwd()+"\renom.log" # separateur de chemin windows
HTH
Bon ok, pour winsound je n'y avais pas pensé. Mais qu'aurais-tu
utilisé à la place pour beeper en cas d'erreur ?
Rien - les programmes qui bippent m'exaspèrent !-)
Mais bon, si tu y tiens vraiment, à toi de voir quelles solutions sont
disponibles suivant les plateformes - en commençant par vérifier si ton
GUI toolkit ne propose pas déjà cette fonctionnalité.
Sinon les variables initialisée avec des valeurs propres à Windows
peuvent facilement être initilisées par des valeurs propres à la
plateforme d'utilisation.
Alors ne t'en prives pas !-)
Ce qui compte, je pense que ce sont les
fonctions utilisées qui doivent être portables.
Pierre dit que j'aurais du faire un prog multiplateformes. Mon programme utilise-t-il donc des fonctions spécifiques à Windows ?
from winsound import * # windows-only dirinit=noudir="C:/" # windows-only nomlog=os.getcwd()+"renom.log" # separateur de chemin windows
HTH
Bon ok, pour winsound je n'y avais pas pensé. Mais qu'aurais-tu utilisé à la place pour beeper en cas d'erreur ?
Rien - les programmes qui bippent m'exaspèrent !-)
Mais bon, si tu y tiens vraiment, à toi de voir quelles solutions sont disponibles suivant les plateformes - en commençant par vérifier si ton GUI toolkit ne propose pas déjà cette fonctionnalité.
Sinon les variables initialisée avec des valeurs propres à Windows peuvent facilement être initilisées par des valeurs propres à la plateforme d'utilisation.
Alors ne t'en prives pas !-)
Ce qui compte, je pense que ce sont les fonctions utilisées qui doivent être portables.
Ce qui est un des intérêts de os.path.join()
Méta-MCI \(MVP\)
Bonsoir !
développer ce genre de programme en multiplateforme
Comme je vois là un joli sujet de trolling, j'en profite allègrement (faut pas m'en vouloir ; ce n'est pas une attaque perso ; c'est pour mettre un peu d'animation).
Aaaahhhh, la "portabilité". Un mot à la mode. Mais, ce mot recouvre quoi ? Il traite de la portabilité d'un programme entre différentes plateformes. OK. Mais, de quelles plateformes parle-t'on ?
En fait, j'ai remarqué que c'est essentiellement une demande faite par certains utilisateurs à propos de logiciels/programmes qui ne tournent pas sur leur plateforme favorite.
Il n'est donc plus question d'universalité ou d'exo-intérêt, mais plutôt "je voudrais que ça tourne sur MA plateforme".
Et, en pratique, il s'agit de Windows et de Linux. Avec, éventuellement, une tolérance pour MacOS. Quand aux autres plateformes, elles sont royalement ignorées.
Si on rapproche ça du fait que la portabilité (applicative) passe souvent par un PPDC (Plus Petit Dénominateur Commun) des différentes plateformes, je pense que faire une application portable est synonyme d'une réduction fonctionnelle. Et, pour moi, cela va à l'encontre des intérêts des utilisateurs pour lesquels on développe.
@-salutations -- Michel Claveau
Bonsoir !
développer ce genre de programme en multiplateforme
Comme je vois là un joli sujet de trolling, j'en profite allègrement
(faut pas m'en vouloir ; ce n'est pas une attaque perso ; c'est pour
mettre un peu d'animation).
Aaaahhhh, la "portabilité". Un mot à la mode.
Mais, ce mot recouvre quoi ? Il traite de la portabilité d'un programme
entre différentes plateformes.
OK.
Mais, de quelles plateformes parle-t'on ?
En fait, j'ai remarqué que c'est essentiellement une demande faite par
certains utilisateurs à propos de logiciels/programmes qui ne tournent
pas sur leur plateforme favorite.
Il n'est donc plus question d'universalité ou d'exo-intérêt, mais plutôt
"je voudrais que ça tourne sur MA plateforme".
Et, en pratique, il s'agit de Windows et de Linux. Avec,
éventuellement, une tolérance pour MacOS. Quand aux autres plateformes,
elles sont royalement ignorées.
Si on rapproche ça du fait que la portabilité (applicative) passe
souvent par un PPDC (Plus Petit Dénominateur Commun) des différentes
plateformes, je pense que faire une application portable est synonyme
d'une réduction fonctionnelle. Et, pour moi, cela va à l'encontre des
intérêts des utilisateurs pour lesquels on développe.
développer ce genre de programme en multiplateforme
Comme je vois là un joli sujet de trolling, j'en profite allègrement (faut pas m'en vouloir ; ce n'est pas une attaque perso ; c'est pour mettre un peu d'animation).
Aaaahhhh, la "portabilité". Un mot à la mode. Mais, ce mot recouvre quoi ? Il traite de la portabilité d'un programme entre différentes plateformes. OK. Mais, de quelles plateformes parle-t'on ?
En fait, j'ai remarqué que c'est essentiellement une demande faite par certains utilisateurs à propos de logiciels/programmes qui ne tournent pas sur leur plateforme favorite.
Il n'est donc plus question d'universalité ou d'exo-intérêt, mais plutôt "je voudrais que ça tourne sur MA plateforme".
Et, en pratique, il s'agit de Windows et de Linux. Avec, éventuellement, une tolérance pour MacOS. Quand aux autres plateformes, elles sont royalement ignorées.
Si on rapproche ça du fait que la portabilité (applicative) passe souvent par un PPDC (Plus Petit Dénominateur Commun) des différentes plateformes, je pense que faire une application portable est synonyme d'une réduction fonctionnelle. Et, pour moi, cela va à l'encontre des intérêts des utilisateurs pour lesquels on développe.
