Bonsoir je recherche une fonction en python si c'est possible pour le
calcul de date
on rentre le date du jour et un certain nombre de jours(soit en mois,
trimesse) et la fonction nour permet d'avoir la date de fin
Merci pour vos reponse
Sinon, il me semble que Python n'est pas un "shell". Ou bien l'est-il?
Pour quelle définition de "shell" ?-) Tu a probablement remarqué que Python proposait un interpréteur interactif
Oui.
- connu aussi sous le nom de "Python shell" -
Je le connaissais plus sous le nom de "interpréteur" et "prompt" plus qu'autre chose.
"prompt" est le diminutif de "command line prompt" (in french: "invitation de ligne de commande" ?). Le mot "shell" ("coquille") désigne originellement un programme permettant à l'utilisateur de communiquer avec le système - en l'occurence par des "lignes de commandes", c'est à dire un langage spécifique. Il existe plusieurs shells pour les systèmes unix, le plus courant sous Linux étant bash (bourne-again shell).
Je trouvais aussi un peu réducteur ou péjoratif d'appeler ça un shell...
La fonction de l'interpréteur interactif Python vis à vis du "système" constitué par l'interpréteur et les bibliothèques disponibles est analogue à celle d'un shell "traditionnel" vis à vis de l'OS. C'est encore plus sensible dans des sytèmes comme Zope quand tu utilises zopectl debug et accèdes à ton instance Zope via l'interpréteur interactif.
Dans ma tete, un "shell" permettait uniquement de: - faire des "programmes" impératifs et itératifs simples
hmmm... la plupart des langages de shell sont effectivement quelque peu limités - disont qu'ils ne sont pas fait pour du développement système !-) Par contre, le style n'est pas toujours si impératif que ça au final. On fait pas mal de pipelines (chainages entrée/sortie d'une série de programmes pour transformer un jeu de données), ce qui correspond à de la composition de fonctions, et quelques opérations ensemblistes (via des programmes comme find).
- faciliter le wrapping des différents binaire présent sur le système
s/binaires/exécutables/g
Un script peut être exécutable sans être un "binaire".
Quand on fait (à peu pres) plus que ça ce n'est plus un simple "shell".
Je pense que tu sous-estimes quelque peu la puissance des "scripts shells", du moins sous unix. Il y a certes des limites très nettes à l'exercice, mais tu serais surpris de ce qu'on peut faire rien qu'en combinant des programmes en ligne de commande.
Ceci étant, le terme de "shell" pour l'interpréteur interactif est à comprendre de façon relative, cf remarque plus haut.
Mihamina Rakotomandimby a écrit :
Bruno Desthuilliers wrote:
Sinon, il me semble que Python n'est pas un "shell". Ou bien l'est-il?
Pour quelle définition de "shell" ?-)
Tu a probablement remarqué que Python proposait un interpréteur
interactif
Oui.
- connu aussi sous le nom de "Python shell" -
Je le connaissais plus sous le nom de "interpréteur" et "prompt" plus
qu'autre chose.
"prompt" est le diminutif de "command line prompt" (in french:
"invitation de ligne de commande" ?). Le mot "shell" ("coquille")
désigne originellement un programme permettant à l'utilisateur de
communiquer avec le système - en l'occurence par des "lignes de
commandes", c'est à dire un langage spécifique. Il existe plusieurs
shells pour les systèmes unix, le plus courant sous Linux étant bash
(bourne-again shell).
Je trouvais aussi un peu réducteur ou péjoratif d'appeler ça un shell...
La fonction de l'interpréteur interactif Python vis à vis du "système"
constitué par l'interpréteur et les bibliothèques disponibles est
analogue à celle d'un shell "traditionnel" vis à vis de l'OS. C'est
encore plus sensible dans des sytèmes comme Zope quand tu utilises
zopectl debug et accèdes à ton instance Zope via l'interpréteur interactif.
Dans ma tete, un "shell" permettait uniquement de:
- faire des "programmes" impératifs et itératifs simples
hmmm... la plupart des langages de shell sont effectivement quelque peu
limités - disont qu'ils ne sont pas fait pour du développement système
!-) Par contre, le style n'est pas toujours si impératif que ça au
final. On fait pas mal de pipelines (chainages entrée/sortie d'une série
de programmes pour transformer un jeu de données), ce qui correspond à
de la composition de fonctions, et quelques opérations ensemblistes (via
des programmes comme find).
- faciliter le wrapping des différents binaire présent sur le système
s/binaires/exécutables/g
Un script peut être exécutable sans être un "binaire".
Quand on fait (à peu pres) plus que ça ce n'est plus un simple "shell".
Je pense que tu sous-estimes quelque peu la puissance des "scripts
shells", du moins sous unix. Il y a certes des limites très nettes à
l'exercice, mais tu serais surpris de ce qu'on peut faire rien qu'en
combinant des programmes en ligne de commande.
Ceci étant, le terme de "shell" pour l'interpréteur interactif est à
comprendre de façon relative, cf remarque plus haut.
Sinon, il me semble que Python n'est pas un "shell". Ou bien l'est-il?
Pour quelle définition de "shell" ?-) Tu a probablement remarqué que Python proposait un interpréteur interactif
Oui.
- connu aussi sous le nom de "Python shell" -
Je le connaissais plus sous le nom de "interpréteur" et "prompt" plus qu'autre chose.
"prompt" est le diminutif de "command line prompt" (in french: "invitation de ligne de commande" ?). Le mot "shell" ("coquille") désigne originellement un programme permettant à l'utilisateur de communiquer avec le système - en l'occurence par des "lignes de commandes", c'est à dire un langage spécifique. Il existe plusieurs shells pour les systèmes unix, le plus courant sous Linux étant bash (bourne-again shell).
Je trouvais aussi un peu réducteur ou péjoratif d'appeler ça un shell...
La fonction de l'interpréteur interactif Python vis à vis du "système" constitué par l'interpréteur et les bibliothèques disponibles est analogue à celle d'un shell "traditionnel" vis à vis de l'OS. C'est encore plus sensible dans des sytèmes comme Zope quand tu utilises zopectl debug et accèdes à ton instance Zope via l'interpréteur interactif.
Dans ma tete, un "shell" permettait uniquement de: - faire des "programmes" impératifs et itératifs simples
hmmm... la plupart des langages de shell sont effectivement quelque peu limités - disont qu'ils ne sont pas fait pour du développement système !-) Par contre, le style n'est pas toujours si impératif que ça au final. On fait pas mal de pipelines (chainages entrée/sortie d'une série de programmes pour transformer un jeu de données), ce qui correspond à de la composition de fonctions, et quelques opérations ensemblistes (via des programmes comme find).
- faciliter le wrapping des différents binaire présent sur le système
s/binaires/exécutables/g
Un script peut être exécutable sans être un "binaire".
Quand on fait (à peu pres) plus que ça ce n'est plus un simple "shell".
Je pense que tu sous-estimes quelque peu la puissance des "scripts shells", du moins sous unix. Il y a certes des limites très nettes à l'exercice, mais tu serais surpris de ce qu'on peut faire rien qu'en combinant des programmes en ligne de commande.
Ceci étant, le terme de "shell" pour l'interpréteur interactif est à comprendre de façon relative, cf remarque plus haut.
Méta-MCI \(MVP\)
Salut !
la puissance des "scripts shells", du moins sous unix
Mouarf. Bin on n'est pas près de voir leur "powershell" détroner nos bon vieux shells unix...
Argumentaire: "powershell c'est orienté objet, *donc* mieux que ces vielleries qui retournent du texte"
Exemple proposé: connaître la taille d'un fichier donné
Solution MS-DOS : essayer de parser le retour de la commande dir.
Commentaire: """ Pas évident maintenant de ne récupérer que la taille du fichier. Il va falloir compter le nombre de lignes et de caractères pour découper la chaine et enfin espérer obtenir en la taille en passant cette commande via le pipe à une autre commande. Fatistidieux ! """
Le problème, c'est pas que dir retourne du texte, c'est qu'il n'y a rien sous ms-dos de comparable à l'éco-système unix. Dans le cas présent, pour connaitre la taille d'un fichier:
stat --format='%s' /chemin/vers/fichier
(ou 'stat -c'%s' si vous êtes pressés)
Voila. Rien à parser. Autre chose ?
Accessoirement, quand il y a effectivement du parsing à faire, on a grep et sed. Pas besoin de "compter le nombre de lignes et de caractères pour découper la chaine" - solution inepte qui ne peux sortir que de l'esprit d'un malheureux n'ayant jamais vu une expression rationnelle.
Allez, salut les guignols de chez MS, continuez à nous faire rire avec vos efforts pathétiques pour faire croire que la roue carrée est une grande innovation...
Méta-MCI (MVP) a écrit :
Salut !
la puissance des "scripts shells", du moins sous unix
Mouarf. Bin on n'est pas près de voir leur "powershell" détroner nos bon
vieux shells unix...
Argumentaire: "powershell c'est orienté objet, *donc* mieux que ces
vielleries qui retournent du texte"
Exemple proposé:
connaître la taille d'un fichier donné
Solution MS-DOS :
essayer de parser le retour de la commande dir.
Commentaire:
"""
Pas évident maintenant de ne récupérer que la taille du fichier. Il va
falloir compter le nombre de lignes et de caractères pour découper la
chaine et enfin espérer obtenir en la taille en passant cette commande
via le pipe à une autre commande. Fatistidieux !
"""
Le problème, c'est pas que dir retourne du texte, c'est qu'il n'y a rien
sous ms-dos de comparable à l'éco-système unix. Dans le cas présent,
pour connaitre la taille d'un fichier:
stat --format='%s' /chemin/vers/fichier
(ou 'stat -c'%s' si vous êtes pressés)
Voila. Rien à parser. Autre chose ?
Accessoirement, quand il y a effectivement du parsing à faire, on a grep
et sed. Pas besoin de "compter le nombre de lignes et de caractères pour
découper la chaine" - solution inepte qui ne peux sortir que de l'esprit
d'un malheureux n'ayant jamais vu une expression rationnelle.
Allez, salut les guignols de chez MS, continuez à nous faire rire avec
vos efforts pathétiques pour faire croire que la roue carrée est une
grande innovation...
Mouarf. Bin on n'est pas près de voir leur "powershell" détroner nos bon vieux shells unix...
Argumentaire: "powershell c'est orienté objet, *donc* mieux que ces vielleries qui retournent du texte"
Exemple proposé: connaître la taille d'un fichier donné
Solution MS-DOS : essayer de parser le retour de la commande dir.
Commentaire: """ Pas évident maintenant de ne récupérer que la taille du fichier. Il va falloir compter le nombre de lignes et de caractères pour découper la chaine et enfin espérer obtenir en la taille en passant cette commande via le pipe à une autre commande. Fatistidieux ! """
Le problème, c'est pas que dir retourne du texte, c'est qu'il n'y a rien sous ms-dos de comparable à l'éco-système unix. Dans le cas présent, pour connaitre la taille d'un fichier:
stat --format='%s' /chemin/vers/fichier
(ou 'stat -c'%s' si vous êtes pressés)
Voila. Rien à parser. Autre chose ?
Accessoirement, quand il y a effectivement du parsing à faire, on a grep et sed. Pas besoin de "compter le nombre de lignes et de caractères pour découper la chaine" - solution inepte qui ne peux sortir que de l'esprit d'un malheureux n'ayant jamais vu une expression rationnelle.
Allez, salut les guignols de chez MS, continuez à nous faire rire avec vos efforts pathétiques pour faire croire que la roue carrée est une grande innovation...
Méta-MCI \(MVP\)
Salut !
Je crains que tu n'aies confusé légèrement sur les bords. La solution héritée de MS/DOS, que tu critiques, est l'ancienne méthode, qui a été remplacée par PowerShell. Dans l'exemple, avec PowerShell, on récupère l'objet (fichier), et l'on a accès à ses propriétés (ici, "length") : $fich = Get-ChildItem chemintoto.dat $fich.length
Cela m'étonne, que tu sois passé ainsi à côté de l'explication. Quoique, à la réflexion, il y a peut-être une explication psychanalytique...
Bon, OK, je retourne boire mon biberon.
@+
Michel Claveau
Salut !
Je crains que tu n'aies confusé légèrement sur les bords. La solution
héritée de MS/DOS, que tu critiques, est l'ancienne méthode, qui a été
remplacée par PowerShell.
Dans l'exemple, avec PowerShell, on récupère l'objet (fichier), et l'on
a accès à ses propriétés (ici, "length") :
$fich = Get-ChildItem chemintoto.dat
$fich.length
Cela m'étonne, que tu sois passé ainsi à côté de l'explication.
Quoique, à la réflexion, il y a peut-être une explication
psychanalytique...
Je crains que tu n'aies confusé légèrement sur les bords. La solution héritée de MS/DOS, que tu critiques, est l'ancienne méthode, qui a été remplacée par PowerShell. Dans l'exemple, avec PowerShell, on récupère l'objet (fichier), et l'on a accès à ses propriétés (ici, "length") : $fich = Get-ChildItem chemintoto.dat $fich.length
Cela m'étonne, que tu sois passé ainsi à côté de l'explication. Quoique, à la réflexion, il y a peut-être une explication psychanalytique...
Bon, OK, je retourne boire mon biberon.
@+
Michel Claveau
Bruno Desthuilliers
Méta-MCI (MVP) a écrit :
Salut !
Je crains que tu n'aies confusé légèrement sur les bords.
Je ne "confusionne" rien. J'ai bien lu et compris le texte en question, merci. Je crains par contre que *tu* n'aie pas bien compris où se situait ma critique - ce qui m'étonne d'ailleurs... Mais il y a peut-être une explication psychanalitique ?-)
Dans le texte de l'exemple, le "raisonnement" est grosso-modo le suivant:
- en MS DOS, pour retrouver la taille d'un fichier, il est nécessaire de parser - manuellement qui plus est - le texte retourné par la commande 'dir' - c'est naze comme solution - donc un système où les commandes retournent du texte est inférieur à un système où les commandes retournent des objets.
C'est bien sûr un syllogisme, dont le schéma est d'ailleurs bien connu: "x est un Y, x est mauvais, donc tous les Y sont mauvais".
La solution héritée de MS/DOS, que tu critiques,
Ca t'a manifestement échappé , mais ce que je critique, c'est le vice de forme du raisonnement employé, lequel, de l'inutilisabilité d'*un* environnement "orienté texte" particulier (le shell ms-dos/Windows), dérive l'inutilisabilité des environnements "orientés texte" *en général* - et ce alors même que des environnements de ce type pleinement fonctionnels et utilisables existent depuis lulure.
Dans l'exemple, avec PowerShell, on récupère l'objet (fichier), et l'on a accès à ses propriétés (ici, "length") : $fich = Get-ChildItem chemintoto.dat $fich.length
Et sous bash:
stat -c'%s' /chemin/vers/toto.dat
Méta-MCI (MVP) a écrit :
Salut !
Je crains que tu n'aies confusé légèrement sur les bords.
Je ne "confusionne" rien. J'ai bien lu et compris le texte en question,
merci. Je crains par contre que *tu* n'aie pas bien compris où se
situait ma critique - ce qui m'étonne d'ailleurs... Mais il y a
peut-être une explication psychanalitique ?-)
Dans le texte de l'exemple, le "raisonnement" est grosso-modo le suivant:
- en MS DOS, pour retrouver la taille d'un fichier, il est nécessaire de
parser - manuellement qui plus est - le texte retourné par la commande 'dir'
- c'est naze comme solution
- donc un système où les commandes retournent du texte est inférieur à
un système où les commandes retournent des objets.
C'est bien sûr un syllogisme, dont le schéma est d'ailleurs bien connu:
"x est un Y, x est mauvais, donc tous les Y sont mauvais".
La solution
héritée de MS/DOS, que tu critiques,
Ca t'a manifestement échappé , mais ce que je critique, c'est le vice de
forme du raisonnement employé, lequel, de l'inutilisabilité d'*un*
environnement "orienté texte" particulier (le shell ms-dos/Windows),
dérive l'inutilisabilité des environnements "orientés texte" *en
général* - et ce alors même que des environnements de ce type
pleinement fonctionnels et utilisables existent depuis lulure.
Dans l'exemple, avec PowerShell, on récupère l'objet (fichier), et l'on
a accès à ses propriétés (ici, "length") :
$fich = Get-ChildItem chemintoto.dat
$fich.length
Je crains que tu n'aies confusé légèrement sur les bords.
Je ne "confusionne" rien. J'ai bien lu et compris le texte en question, merci. Je crains par contre que *tu* n'aie pas bien compris où se situait ma critique - ce qui m'étonne d'ailleurs... Mais il y a peut-être une explication psychanalitique ?-)
Dans le texte de l'exemple, le "raisonnement" est grosso-modo le suivant:
- en MS DOS, pour retrouver la taille d'un fichier, il est nécessaire de parser - manuellement qui plus est - le texte retourné par la commande 'dir' - c'est naze comme solution - donc un système où les commandes retournent du texte est inférieur à un système où les commandes retournent des objets.
C'est bien sûr un syllogisme, dont le schéma est d'ailleurs bien connu: "x est un Y, x est mauvais, donc tous les Y sont mauvais".
La solution héritée de MS/DOS, que tu critiques,
Ca t'a manifestement échappé , mais ce que je critique, c'est le vice de forme du raisonnement employé, lequel, de l'inutilisabilité d'*un* environnement "orienté texte" particulier (le shell ms-dos/Windows), dérive l'inutilisabilité des environnements "orientés texte" *en général* - et ce alors même que des environnements de ce type pleinement fonctionnels et utilisables existent depuis lulure.
Dans l'exemple, avec PowerShell, on récupère l'objet (fichier), et l'on a accès à ses propriétés (ici, "length") : $fich = Get-ChildItem chemintoto.dat $fich.length
Et sous bash:
stat -c'%s' /chemin/vers/toto.dat
Cémoi
<big snip>
C'est rigolo, parce qu'à la page "The Script Center Script Repository: Sample Windows PowerShell Scripts" (http://www.microsoft.com/technet/scriptcenter/scripts/msh/default.mspx?mfr=true) on trouve dans le panneau latéral un répertoire "Additional Scripting Languages >> Python Scripts" qui donne des exemples de scripts Python, équivalents d'un point de vue fonctionnel à ceux fournis en PowerShell. Les exemples me paraissent non dénués d'intérêt pour qui veut administrer des plateformes Windows en Python ...
HTH,
Laurent
<big snip>
C'est rigolo, parce qu'à la page "The Script Center Script Repository:
Sample Windows PowerShell Scripts"
(http://www.microsoft.com/technet/scriptcenter/scripts/msh/default.mspx?mfr=true)
on trouve dans le panneau latéral un répertoire "Additional Scripting
Languages >> Python Scripts" qui donne des exemples de scripts Python,
équivalents d'un point de vue fonctionnel à ceux fournis en PowerShell.
Les exemples me paraissent non dénués d'intérêt pour qui veut
administrer des plateformes Windows en Python ...
C'est rigolo, parce qu'à la page "The Script Center Script Repository: Sample Windows PowerShell Scripts" (http://www.microsoft.com/technet/scriptcenter/scripts/msh/default.mspx?mfr=true) on trouve dans le panneau latéral un répertoire "Additional Scripting Languages >> Python Scripts" qui donne des exemples de scripts Python, équivalents d'un point de vue fonctionnel à ceux fournis en PowerShell. Les exemples me paraissent non dénués d'intérêt pour qui veut administrer des plateformes Windows en Python ...
