Je ne connais pas ipython mais si c'est ce à quoi je pense, c'est juste un shell python interactif un peu amélioré.
Tout comme python, il ne t'offre pas un véritable accès aux entités du système en tant qu'objets.
J'illustre ca par un exemple:
Je veux ouvrir le répertoire courant et récupérer la liste de tous les fichiers qu'il contient
import os
l=os.listdir('.')
l
['..... j'obtient tous les fichiers du système dans une liste...]
print l[0].__class__
--- > <type 'str'>
On obtient une chaine au lieu d'un objet "File"
J'ai la complétion sur une chaine et non sur un objet File.
Je suis donc obligé de me palucher toute la doc de python pour connaitre la fonction d'accès du groupe sur ce fichier et découvrir stat dans le module os
os.stat(l[0]).st_gid
qui me renvoie encore un type de base.
Avec un shell objet j'aurais : l|0].get_Group()
et je pourrais lui appliquer un setGroup à la volée
Remarquez que ce n'est pas inhérent au langage python mais simplement à la conception de la librairie qui est parti du paradigme procédural (wrapper au dessus de POSIX j'imagine)
Pour obtenir un truc équivalent sous Linux, il faudrait faire une rétroconception sur tout le système puis créer une API objet qui serait en fait une facade au dessus des fonctions de base du noyau (écrites en C)
Ainsi tous les langages et frameworks pourraient s'appuyer dessus
y compris Gnome et KDE qui proposent déjà à travers DBUS un accès à des objets d'applications.
J'imagine que c'est ce qui a été fait avec .NET car je doute que Windows soit un OS purement objet.
A ce propos Timaniac :
Est-ce que Mono propose cette API ? Si tel est le cas, il suffit de se baser dessus pour se créer un shell à la powershell.(avec une syntaxe Ironpython ca serait top)
Je me doute qu'étant donné la différence de conception entre les 2 os, il doit y avoir des incompatibilités (genre ACL pour Windows et droits à la UNIX par défaut si l'on active pas les ACL sous Linux)
[^] # Re: comme dcop/dbus ? bsh , js shell, ipython
Posté par golum . En réponse au journal PowerShell: tapez rm -rf c:\Windows ! ;). Évalué à 3.
Tout comme python, il ne t'offre pas un véritable accès aux entités du système en tant qu'objets.
J'illustre ca par un exemple:
Je veux ouvrir le répertoire courant et récupérer la liste de tous les fichiers qu'il contient
On obtient une chaine au lieu d'un objet "File"
J'ai la complétion sur une chaine et non sur un objet File.
Je suis donc obligé de me palucher toute la doc de python pour connaitre la fonction d'accès du groupe sur ce fichier et découvrir stat dans le module os
os.stat(l[0]).st_gid
qui me renvoie encore un type de base.
Avec un shell objet j'aurais : l|0].get_Group()
et je pourrais lui appliquer un setGroup à la volée
Remarquez que ce n'est pas inhérent au langage python mais simplement à la conception de la librairie qui est parti du paradigme procédural (wrapper au dessus de POSIX j'imagine)
Pour obtenir un truc équivalent sous Linux, il faudrait faire une rétroconception sur tout le système puis créer une API objet qui serait en fait une facade au dessus des fonctions de base du noyau (écrites en C)
Ainsi tous les langages et frameworks pourraient s'appuyer dessus
y compris Gnome et KDE qui proposent déjà à travers DBUS un accès à des objets d'applications.
J'imagine que c'est ce qui a été fait avec .NET car je doute que Windows soit un OS purement objet.
A ce propos Timaniac :
Est-ce que Mono propose cette API ? Si tel est le cas, il suffit de se baser dessus pour se créer un shell à la powershell.(avec une syntaxe Ironpython ca serait top)
Je me doute qu'étant donné la différence de conception entre les 2 os, il doit y avoir des incompatibilités (genre ACL pour Windows et droits à la UNIX par défaut si l'on active pas les ACL sous Linux)
Mono permet t'il réellement l'interopérabilité ?