Il y a deux points principaux à considérer ici:
- Il est raisonnable de s'attendre à ce que le résultat de
'/segment/segment/'.split('/')
soit égal à ['segment', 'segment']
, mais cela perd alors des informations. Si cela split()
fonctionnait comme vous le souhaitiez, si je vous dis cela a.split('/') == ['segment', 'segment']
, vous ne pouvez pas me dire ce que a
c'était.
- Quel devrait être le résultat
'a//b'.split()
? ['a', 'b']
?, ou ['a', '', 'b']
? Par exemple, faut-il split()
fusionner les délimiteurs adjacents? Si tel est le cas, il sera très difficile d'analyser les données délimitées par un caractère, et certains champs peuvent être vides. Je suis assez sûr qu'il ya beaucoup de gens qui font veulent les valeurs vides dans le résultat pour le cas ci - dessus!
Au final, cela se résume à deux choses:
Cohérence: si j'ai des n
délimiteurs, dans a
, je récupère les n+1
valeurs après le split()
.
Il devrait être possible de faire des choses complexes, et faciles de faire des choses simples: si vous voulez ignorer les chaînes vides à la suite de split()
, vous pouvez toujours faire:
def mysplit(s, delim=None):
return [x for x in s.split(delim) if x]
mais si on ne veut pas ignorer les valeurs vides, on devrait pouvoir le faire.
Le langage doit choisir une définition de: split()
il y a trop de cas d'utilisation différents pour satisfaire les exigences de chacun par défaut. Je pense que le choix de Python est bon, et le plus logique. (En passant, l'une des raisons pour lesquelles je n'aime pas C strtok()
est parce qu'il fusionne les délimiteurs adjacents, ce qui rend extrêmement difficile de faire une analyse / tokenisation sérieuse avec lui.)
Il y a une exception: a.split()
sans argument, serre les espaces blancs consécutifs, mais on peut affirmer que c'est la bonne chose à faire dans ce cas. Si vous ne voulez pas le comportement, vous pouvez toujours le faire a.split(' ')
.