Le 01/06/2021 09:21, Nicolas a écrit :Une idée qui me vient comme ça : Est-ce qu'une chaine json serait
adaptée Í ce que tu veux faire ? Ca aurait l'intérêt d'être plus
universel et non dépendant de l'indentation.
J'avais regardé JSON, et c'est moins adapté que configparser pour
plusieurs raisons. En particulier, tout comme TOML ou YAML, c'est le
fichier de config qui détermine le type des données. Alors c'est très
adapté comme format d'échange entre deux programmes, y compris sur
des architectures différentes, mais ça ne correspond pas Í mon besoin.
Je ne vois pas o͹ il est question de type de données dans ta description
du problème. Tu écris/lis des chaines de caractères dans un fichier.
Ensuite, libre Í toi d'interpréter ces chaines de caractères comme tu
l'entends. Ce que tu fais déjÍ avec ton propre parseur...
Ah oui, tu veux dire que je pourrais utiliser un format TOML ou JSON
dans lequel toutes les données seraient des chaÍ®nes de caractères, donc
sans utiliser la possibilité d'exprimer des tableaux ou des dictionnaires
par exemple ?
Du coup je trouve dommage d'ajouter de la complexité (avec guillemets et
accolades) si c'est pour sous-utiliser les possibilités du format. D'autant
plus que mon seul problème concernait *un* type de données parmi tous ceux
que j'utilise,
et que je l'ai résolu d'une façon qui préserve la philosophie
de python (l'indentation pour indiquer la struture). La seule différence
c'est que j'indente avec un choix de caractères qui ajoute le « | » aux
seules espaces et tabulations.
Le 01/06/2021 09:21, Nicolas a écrit :
Une idée qui me vient comme ça : Est-ce qu'une chaine json serait
adaptée Í ce que tu veux faire ? Ca aurait l'intérêt d'être plus
universel et non dépendant de l'indentation.
J'avais regardé JSON, et c'est moins adapté que configparser pour
plusieurs raisons. En particulier, tout comme TOML ou YAML, c'est le
fichier de config qui détermine le type des données. Alors c'est très
adapté comme format d'échange entre deux programmes, y compris sur
des architectures différentes, mais ça ne correspond pas Í mon besoin.
Je ne vois pas o͹ il est question de type de données dans ta description
du problème. Tu écris/lis des chaines de caractères dans un fichier.
Ensuite, libre Í toi d'interpréter ces chaines de caractères comme tu
l'entends. Ce que tu fais déjÍ avec ton propre parseur...
Ah oui, tu veux dire que je pourrais utiliser un format TOML ou JSON
dans lequel toutes les données seraient des chaÍ®nes de caractères, donc
sans utiliser la possibilité d'exprimer des tableaux ou des dictionnaires
par exemple ?
Du coup je trouve dommage d'ajouter de la complexité (avec guillemets et
accolades) si c'est pour sous-utiliser les possibilités du format. D'autant
plus que mon seul problème concernait *un* type de données parmi tous ceux
que j'utilise,
et que je l'ai résolu d'une façon qui préserve la philosophie
de python (l'indentation pour indiquer la struture). La seule différence
c'est que j'indente avec un choix de caractères qui ajoute le « | » aux
seules espaces et tabulations.
Le 01/06/2021 09:21, Nicolas a écrit :Une idée qui me vient comme ça : Est-ce qu'une chaine json serait
adaptée Í ce que tu veux faire ? Ca aurait l'intérêt d'être plus
universel et non dépendant de l'indentation.
J'avais regardé JSON, et c'est moins adapté que configparser pour
plusieurs raisons. En particulier, tout comme TOML ou YAML, c'est le
fichier de config qui détermine le type des données. Alors c'est très
adapté comme format d'échange entre deux programmes, y compris sur
des architectures différentes, mais ça ne correspond pas Í mon besoin.
Je ne vois pas o͹ il est question de type de données dans ta description
du problème. Tu écris/lis des chaines de caractères dans un fichier.
Ensuite, libre Í toi d'interpréter ces chaines de caractères comme tu
l'entends. Ce que tu fais déjÍ avec ton propre parseur...
Ah oui, tu veux dire que je pourrais utiliser un format TOML ou JSON
dans lequel toutes les données seraient des chaÍ®nes de caractères, donc
sans utiliser la possibilité d'exprimer des tableaux ou des dictionnaires
par exemple ?
Du coup je trouve dommage d'ajouter de la complexité (avec guillemets et
accolades) si c'est pour sous-utiliser les possibilités du format. D'autant
plus que mon seul problème concernait *un* type de données parmi tous ceux
que j'utilise,
et que je l'ai résolu d'une façon qui préserve la philosophie
de python (l'indentation pour indiquer la struture). La seule différence
c'est que j'indente avec un choix de caractères qui ajoute le « | » aux
seules espaces et tabulations.
Je ne vois pas o͹ il est question de type de données dans ta description
du problème. Tu écris/lis des chaines de caractères dans un fichier.
Ensuite, libre Í toi d'interpréter ces chaines de caractères comme tu
l'entends. Ce que tu fais déjÍ avec ton propre parseur...
Ah oui, tu veux dire que je pourrais utiliser un format TOML ou JSON
dans lequel toutes les données seraient des chaÍ®nes de caractères, donc
sans utiliser la possibilité d'exprimer des tableaux ou des dictionnaires
par exemple ?
Tu peux très bien utiliser des dictionnaires et des listes pour faire
les regroupements logiques dont tu as besoin.
En Python :
{"OR" : [{"from" : "/un spammeur /"},
{"from" : "/autre spammeur
/"},
{"AND" : [{"from" : "/un autre encore /"},
{"!" : "message-id //"},
{"!" : "message-id //"}
]
},
Du coup je trouve dommage d'ajouter de la complexité (avec guillemets et
accolades) si c'est pour sous-utiliser les possibilités du format. D'autant
plus que mon seul problème concernait *un* type de données parmi tous ceux
que j'utilise,
Pas de complexité, bien au contraire, si tu utilises les fonctions de
conversion Python/JSON et JSON/Python de la bibliothèque standard.
C'est même plus facile, que de parser un morceaux de fichier
manuellement. Au chargement, tu récupères une structure de données
Python (dict et list) toute cuite.
A l'écriture, tu écris la chaine JSON dans le fichier de config.
et que je l'ai résolu d'une façon qui préserve la philosophie
de python (l'indentation pour indiquer la struture). La seule différence
c'est que j'indente avec un choix de caractères qui ajoute le « | » aux
seules espaces et tabulations.
Ce n'est pas parce que les sources Python utilisent l'indentation pour
marquer les blocs de code que les fichiers de données doivent être sur
le même principe. Et heureusement.
Je ne vois pas o͹ il est question de type de données dans ta description
du problème. Tu écris/lis des chaines de caractères dans un fichier.
Ensuite, libre Í toi d'interpréter ces chaines de caractères comme tu
l'entends. Ce que tu fais déjÍ avec ton propre parseur...
Ah oui, tu veux dire que je pourrais utiliser un format TOML ou JSON
dans lequel toutes les données seraient des chaÍ®nes de caractères, donc
sans utiliser la possibilité d'exprimer des tableaux ou des dictionnaires
par exemple ?
Tu peux très bien utiliser des dictionnaires et des listes pour faire
les regroupements logiques dont tu as besoin.
En Python :
{"OR" : [{"from" : "/un spammeur <addresse_du_spammeur@domaine.exemple>/"},
{"from" : "/autre spammeur
<adresse_de_l_autre_spammeur@truc.bidule>/"},
{"AND" : [{"from" : "/un autre encore <encore@son.domaine>/"},
{"!" : "message-id /<abcdef@son.domaine>/"},
{"!" : "message-id /<ghijkl@son.domaine>/"}
]
},
Du coup je trouve dommage d'ajouter de la complexité (avec guillemets et
accolades) si c'est pour sous-utiliser les possibilités du format. D'autant
plus que mon seul problème concernait *un* type de données parmi tous ceux
que j'utilise,
Pas de complexité, bien au contraire, si tu utilises les fonctions de
conversion Python/JSON et JSON/Python de la bibliothèque standard.
C'est même plus facile, que de parser un morceaux de fichier
manuellement. Au chargement, tu récupères une structure de données
Python (dict et list) toute cuite.
A l'écriture, tu écris la chaine JSON dans le fichier de config.
et que je l'ai résolu d'une façon qui préserve la philosophie
de python (l'indentation pour indiquer la struture). La seule différence
c'est que j'indente avec un choix de caractères qui ajoute le « | » aux
seules espaces et tabulations.
Ce n'est pas parce que les sources Python utilisent l'indentation pour
marquer les blocs de code que les fichiers de données doivent être sur
le même principe. Et heureusement.
Je ne vois pas o͹ il est question de type de données dans ta description
du problème. Tu écris/lis des chaines de caractères dans un fichier.
Ensuite, libre Í toi d'interpréter ces chaines de caractères comme tu
l'entends. Ce que tu fais déjÍ avec ton propre parseur...
Ah oui, tu veux dire que je pourrais utiliser un format TOML ou JSON
dans lequel toutes les données seraient des chaÍ®nes de caractères, donc
sans utiliser la possibilité d'exprimer des tableaux ou des dictionnaires
par exemple ?
Tu peux très bien utiliser des dictionnaires et des listes pour faire
les regroupements logiques dont tu as besoin.
En Python :
{"OR" : [{"from" : "/un spammeur /"},
{"from" : "/autre spammeur
/"},
{"AND" : [{"from" : "/un autre encore /"},
{"!" : "message-id //"},
{"!" : "message-id //"}
]
},
Du coup je trouve dommage d'ajouter de la complexité (avec guillemets et
accolades) si c'est pour sous-utiliser les possibilités du format. D'autant
plus que mon seul problème concernait *un* type de données parmi tous ceux
que j'utilise,
Pas de complexité, bien au contraire, si tu utilises les fonctions de
conversion Python/JSON et JSON/Python de la bibliothèque standard.
C'est même plus facile, que de parser un morceaux de fichier
manuellement. Au chargement, tu récupères une structure de données
Python (dict et list) toute cuite.
A l'écriture, tu écris la chaine JSON dans le fichier de config.
et que je l'ai résolu d'une façon qui préserve la philosophie
de python (l'indentation pour indiquer la struture). La seule différence
c'est que j'indente avec un choix de caractères qui ajoute le « | » aux
seules espaces et tabulations.
Ce n'est pas parce que les sources Python utilisent l'indentation pour
marquer les blocs de code que les fichiers de données doivent être sur
le même principe. Et heureusement.
A l'écriture, tu écris la chaine JSON dans le fichier de config.
L'écriture se fait Í la mimine avec un éditeur de texte, voire dans certains
cas en ligne de commande. Ce n'est jamais le programme qui l'écrit.
A l'écriture, tu écris la chaine JSON dans le fichier de config.
L'écriture se fait Í la mimine avec un éditeur de texte, voire dans certains
cas en ligne de commande. Ce n'est jamais le programme qui l'écrit.
A l'écriture, tu écris la chaine JSON dans le fichier de config.
L'écriture se fait Í la mimine avec un éditeur de texte, voire dans certains
cas en ligne de commande. Ce n'est jamais le programme qui l'écrit.
A l'écriture, tu écris la chaine JSON dans le fichier de config.
L'écriture se fait Í la mimine avec un éditeur de texte, voire dans certains
cas en ligne de commande. Ce n'est jamais le programme qui l'écrit.
Ah, ça ne faisait pas partie du cahier des charges ;)
Mais dans ce cas, pourquoi vouloir utiliser un fichier .ini qui utilise
un formatage qui ne te convient pas (tu es obligé de rajouter des | pour
palier au problème) ?
A l'écriture, tu écris la chaine JSON dans le fichier de config.
L'écriture se fait Í la mimine avec un éditeur de texte, voire dans certains
cas en ligne de commande. Ce n'est jamais le programme qui l'écrit.
Ah, ça ne faisait pas partie du cahier des charges ;)
Mais dans ce cas, pourquoi vouloir utiliser un fichier .ini qui utilise
un formatage qui ne te convient pas (tu es obligé de rajouter des | pour
palier au problème) ?
A l'écriture, tu écris la chaine JSON dans le fichier de config.
L'écriture se fait Í la mimine avec un éditeur de texte, voire dans certains
cas en ligne de commande. Ce n'est jamais le programme qui l'écrit.
Ah, ça ne faisait pas partie du cahier des charges ;)
Mais dans ce cas, pourquoi vouloir utiliser un fichier .ini qui utilise
un formatage qui ne te convient pas (tu es obligé de rajouter des | pour
palier au problème) ?
Le 02/06/2021 10:26, Nicolas a écrit :A l'écriture, tu écris la chaine JSON dans le fichier de config.
L'écriture se fait Í la mimine avec un éditeur de texte, voire dans certains
cas en ligne de commande. Ce n'est jamais le programme qui l'écrit.
Ah, ça ne faisait pas partie du cahier des charges ;)
Au départ, la question était seulement « peut-on conserver les espaces dans
des valeurs multilignes avec ConfigParser ». Je n'ai demandé Í personne de
concevoir le programme Í ma place. ;-)
Comme on m'a proposé d'autres choix j'ai voulu évaluer honnêtement l'intérêt
mais aussi les inconvénients de ces autres choix. D'ailleurs je ne le regrette
pas car il est toujours intéressant de réfléchir Í d'autres possibilités
auxquelles on n'aurait pas pensé de prime abord. Et je te remercie très
sincèrement pour cela, ainsi que Julien et Alain.
Mais maintenant je peux marquer mon problème [RÉSOLU] puisque c'est le cas.
Cordialement,
Le 02/06/2021 10:26, Nicolas a écrit :
A l'écriture, tu écris la chaine JSON dans le fichier de config.
L'écriture se fait Í la mimine avec un éditeur de texte, voire dans certains
cas en ligne de commande. Ce n'est jamais le programme qui l'écrit.
Ah, ça ne faisait pas partie du cahier des charges ;)
Au départ, la question était seulement « peut-on conserver les espaces dans
des valeurs multilignes avec ConfigParser ». Je n'ai demandé Í personne de
concevoir le programme Í ma place. ;-)
Comme on m'a proposé d'autres choix j'ai voulu évaluer honnêtement l'intérêt
mais aussi les inconvénients de ces autres choix. D'ailleurs je ne le regrette
pas car il est toujours intéressant de réfléchir Í d'autres possibilités
auxquelles on n'aurait pas pensé de prime abord. Et je te remercie très
sincèrement pour cela, ainsi que Julien et Alain.
Mais maintenant je peux marquer mon problème [RÉSOLU] puisque c'est le cas.
Cordialement,
Le 02/06/2021 10:26, Nicolas a écrit :A l'écriture, tu écris la chaine JSON dans le fichier de config.
L'écriture se fait Í la mimine avec un éditeur de texte, voire dans certains
cas en ligne de commande. Ce n'est jamais le programme qui l'écrit.
Ah, ça ne faisait pas partie du cahier des charges ;)
Au départ, la question était seulement « peut-on conserver les espaces dans
des valeurs multilignes avec ConfigParser ». Je n'ai demandé Í personne de
concevoir le programme Í ma place. ;-)
Comme on m'a proposé d'autres choix j'ai voulu évaluer honnêtement l'intérêt
mais aussi les inconvénients de ces autres choix. D'ailleurs je ne le regrette
pas car il est toujours intéressant de réfléchir Í d'autres possibilités
auxquelles on n'aurait pas pensé de prime abord. Et je te remercie très
sincèrement pour cela, ainsi que Julien et Alain.
Mais maintenant je peux marquer mon problème [RÉSOLU] puisque c'est le cas.
Cordialement,