>>> os.path.basename('http://example.com/file.txt')
'file.txt'
.. et je pensais que os.path.* fonctionne uniquement sur les chemins locaux et non sur les URL? Notez que l'exemple ci-dessus a été exécuté sur Windows aussi .. avec un résultat similaire.os.path.basename fonctionne avec les URL, pourquoi?
Dans la pratique de nombreuses fonctions de os.path ne sont que des fonctions de manipulation de chaîne (qui vient se être particulièrement pratique pour la manipulation de chemin) - et puisque c'est anodin et parfois à portée de main, tout en parlant officiellement « incorrect », je doute que cela changer de sitôt - pour plus de détails, utilisez ce qui suit simple-liner à une coquille/invite de commande:
$ python -c"import sys; import StringIO; x = StringIO.StringIO(); sys.stdout = x; import this; sys.stdout = sys.__stdout__; print x.getvalue().splitlines()[10][9:]"
Ou, pour Python 3:
$ python -c"import sys; import io; x = io.StringIO(); sys.stdout = x; import this; sys.stdout = sys.__stdout__; print(x.getvalue().splitlines()[10][9:])"
Sur les fenêtres, regardez le code source: C: \ Python25 \ Lib \ ntpath.py
def basename(p):
"""Returns the final component of a pathname"""
return split(p)[1]
os.path.split (dans le même fichier) juste split "\" (et STH. d'autre)
utilise 'os.path.basename' sur les URL la façon pythonique d'extraire ce type d'information de leur part?ou dois-je utiliser 'urlpare.urparse ('
@naxa désolé pour la réponse de retard, je ne peux pas dire que c'est pythonique, pensé Il semble aller chemin/filepath.Base "support" url aussi. Je préfère en quelque sorte urlparse pour url handle. – sunqiang
Utilisez la source Luke:
def basename(p):
"""Returns the final component of a pathname"""
i = p.rfind('/') + 1
return p[i:]
Modifier (réponse à la clarification):
Cela fonctionne pour les URL par accident, c'est tout. À cause de cela, l'exploitation de son comportement pourrait être considérée comme une odeur de code par certains.
Essayer de « réparer » (vérifier si le chemin passé n'est pas URL) est étonnamment difficile
www.google.com/test.php
[email protected]/12
./src/bin/doc/goto.c
sont en même temps les chemins corrects et les URL (par rapport), est donc le http:/hello.txt (un/, et seulement sur Linux, et c'est un peu stupide :)). Vous pouvez le "réparer" pour les URLs absolus, mais ceux qui sont relatifs continueront à fonctionner. Gérer un cas particulier différemment est un grand non non dans le monde python.
Pour résumer: importer ce
Pourquoi? Parce que c'est utile pour analyser les URL ainsi que les chemins de fichiers locaux. Pourquoi pas?
Parce que c'est dans le module os.path, et ce n'est pas un chemin tel que compris par le système d'exploitation si vous utilisez Windows; le séparateur de chemin est différent. Je crois que/est un caractère de nom de fichier valide dans Windows, ce qui rendrait un URL un nom de fausse valide, et ce comportement incorrect. Je ne suis pas un utilisateur Windows, donc tout ou partie de ce commentaire pourrait être un charabia. – SpoonMeiser
@SpoonMeiser, l'implémentation de la bibliothèque C par Microsoft vous permet en fait d'utiliser/comme une alternative valide à \ (l'OS lui-même, au niveau de syscall/Win32API, a fait jusqu'à un certain point, mais je pense que ça n'existe pas ;-). –
@Alex Martelli, Si c'est encore vrai, alors cela aurait du sens. – SpoonMeiser
Forw ard slash est également un délimiteur de chemin acceptable dans Windows. C'est simplement que la ligne de commande n'accepte pas les chemins commençant par un/car ce caractère est réservé aux commutateurs args.
Clarification: Je ne parle pas de/pourquoi/cela fonctionne (pour lequel le code source est évidemment aller loin); Je demande plutôt pourquoi devrait-il fonctionner du tout (par la politique - en particulier sur Windows 'est le séparateur de chemin) –
Microsoft OS acceptent '/' barre oblique comme un séparateur de chemin de 'Dos 2', bien que de' Dos 3' en utilisant '/' a été désactivé par la commande shell (ce n'est plus le cas) car elle était en conflit avec la notation de l'option de ligne de commande. A cause de cela, de nombreuses implémentations ne sont tout simplement pas conscientes de la validité de '/'. Python est apparemment. En outre, vous ne pouvez pas utiliser les barres obliques avec le préfixe '" \\? \ "'. sources http://bytes.com/topic/python/answers/23123-when-did-windows-start-accepting-forward-slash-path-separator et http://msdn.microsoft.com/fr-fr/library /aa365247(VS.85).aspx#paths – n611x007