Je vais faire simple puisque je suppose qu'une dépêche en parlera plus en détails.
On en parlait depuis des années : depuis qu'en 2000 Guido van Rossum l'avait baptisé pour être précis. Python 3000 (aka Py3k, ou tout simplement Python 3.0) est la nouvelle version de Python qui n'a pas peur de briser la compatibilité avec les versions antérieures pour corriger les erreurs de conception.
A l'origine, c'est Python 2.x qui devait briser cette compatibilité mais les modifications ont été légères. Python 3000, bien qu'il reste assez similaire à 2.5 dans la forme, change pas mal dans le fond, et notamment au niveau de l'API C qui permet l'interfaçage avec d'autres langages ce qui rend caduque de nombreux outils existants.
Python 2.6, qui est sorti il y a deux mois, est compatible au maximum avec 2.5 et 3000, en vue d'offrir une migration en douceur. Il offre notamment l'option "-3" en ligne de commande pour afficher les avertissements en mode Python 3000.
L'annonce : http://mail.python.org/pipermail/python-list/2008-December/5(...)
Les nouveautés :
http://docs.python.org/dev/3.0/whatsnew//3.0.html
Le journal de godzom qui parlait de l'alpha: https://linuxfr.org//~godzom/25193.html
Happy hacking
Journal Python 3000 est sorti
4
déc.
2008
# Je suppose qu'une dépêche…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9.
[^] # Re: Je suppose qu'une dépêche…
Posté par Victor STINNER (site web personnel) . Évalué à 4.
[^] # Re: Je suppose qu'une dépêche…
Posté par BAud (site web personnel) . Évalué à 2.
http://demoll.tuxfamily.org/linuxfr/NewsPython3000 si vous souhaitez prendre des notes et l'éditer à plusieurs claviers ;-)
(rien dans le pipe actuellement comme dirait Magritte).
[^] # Re: Je suppose qu'une dépêche…
Posté par smc . Évalué à 2.
D'autres questions ? :)
[^] # Re: Je suppose qu'une dépêche…
Posté par Mr Kapouik (site web personnel) . Évalué à 1.
Pourquoi la vie, l'univers et tout le reste ?
[^] # Re: Je suppose qu'une dépêche…
Posté par Thomas Douillard . Évalué à 0.
[^] # Re: Je suppose qu'une dépêche…
Posté par yellowiscool . Évalué à 0.
Envoyé depuis mon lapin.
[^] # Re: Je suppose qu'une dépêche…
Posté par Octabrain . Évalué à -1.
[^] # Re: Je suppose qu'une dépêche…
Posté par smc . Évalué à 3.
[^] # Re: Je suppose qu'une dépêche…
Posté par jcs (site web personnel) . Évalué à 7.
C'est triste ton avis sur les dépêches.
# la vraie nouveauté
Posté par B16F4RV4RD1N . Évalué à -4.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: la vraie nouveauté
Posté par godzom . Évalué à 10.
from __future__ import bracesla réponse est toujours la même:
SyntaxError: not a chanceJe pense que ça ne sera pas pour tout de suite....
[^] # Re: la vraie nouveauté
Posté par CrEv (site web personnel) . Évalué à 7.
[^] # Re: la vraie nouveauté
Posté par Laurent A. . Évalué à 5.
[^] # Re: la vraie nouveauté
Posté par Larry Cow . Évalué à 5.
[^] # Re: la vraie nouveauté
Posté par Victor STINNER (site web personnel) . Évalué à 10.
l=lambda(i):lambda(l):i.__getattribute__(\
O(l));i=lambda(i):l(__import__(O(i)));j=(\
ord,''.join);o=lambda(l):i('speniy')(l);O\
=lambda(I):j[1](chr((j[0](l)-i)%0x100)for\
(i,l)in(enumerate(I)));k=i('_`dxmqzpvhi')\
;k=(k('rbpji'),k('ewco'),k('ljuw'),l(o(''\
'speniy')(o('AGaLRJZ'),o('SPENcXZYMJW')))\
);I=i('iuguxtus{')('tbmh{mosm');i=l([k[-1\
](i[0])(*i[1:])for(i)in(('sfvvshqvx}',o(\
'SPNbWTIRM]'),o('SPaUIZYLIMN]'),1,),('bj'\
'pg',('',010*1010),),('ljuwis',1),('adeh'\
'ty',))][-1][0]);k=k[:-1];i=(i('rfey'),i(\
'sfpg'));k[-1](i[1]("%s\n"%k[1](j[-1](I(\
lambda(I):j[0](I)^10,(i[0](1)for(k)in(k[0\
](101)))))))for(O)in(k[0](1010)))
Tiens, il n'y a aucune espace.
http://haypo.hachoir.org/trac/browser/misc/obscu.py
[^] # Re: la vraie nouveauté
Posté par fearan . Évalué à 9.
Avec du C, java, c++, où l'indentation est définie par des accolades tu peux toujours réindenter avec n'importe quel bon éditeur de texte.
Sur du python, tant que t'est tout seul ça va; en groupe, tu vas toujours avoir le petit nouveau qui va arriver jouer avec des espace au lieu de tabulation (ou vice versa), ou avoir des tabulation de 4 au lieu de 8...
Le jours ou tu voudra rajouter une condition, tu vas sélectionner un paquet de ligne indenter, et au passage oublier une ligne...
enfin bref pour avoir bossé avec du python, cette indentation par bloc faisait plus de mal que de bien, mais pour le reste, c'est pas mal; même si j'ai tendance à préférer le perl, mais pour ne pas lancer de troll, je ne préciserai pas pourquoi.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: la vraie nouveauté
Posté par CrEv (site web personnel) . Évalué à 5.
Il y aura toujours qqn qui mettera des espaces, des tabs, etc d'où le principe de convention de codage
En c, java, c++, etc on pourra toujours avoir du code moisi (dans la présentation)
Et pourquoi en python on ne pourrait pas réindenter avec un éditeur comme c'est fait pour c, java, etc ?
Et le fait d'avoir des accolades ne permet pas forcément d'avoir des codes propres et facilement indentables.
Il n'y a qu'à lire du javascript par exemple
allez, un petit exemple bien galère à indenter "proprement" :
(et encore, là il n'y a qu'une variable et aucune fonction à l'intérieur... ;-) )
var template = [
["div", {
name: ID_TAB_CONT,
children: [
["tabview", {
name: ID_TAB,
tabs: [_("global"), _("byAction"), _("byUser")],
children: [
["tab", {
children: [
["title", {
titleSize: 3,
text: _("titleGlobalUsage")
}],
["div", {
name: ID_CHART_GLOBAL_USAGE,
cssClass: CHART_H
}],
["title", {
titleSize: 3,
text: _("titleUsagePerHour")
}],
["div", {
name: ID_CHART_GLOBAL_PER_HOUR,
cssClass: CHART_H
}]
]
}],
["tab", {
children: [
["accordionview", {
children: [
["accordion", {
text: _("search"),
children: [
["title", {
titleSize: 3,
text: _("titleSearch")
}],
["div", {
name: ID_CHART_ACTION_search_total,
cssClass: CHART_H
}],
["title", {
titleSize: 3,
text: _("titleSearchAvg")
}],
["div", {
name: ID_CHART_ACTION_search_average,
cssClass: CHART_H
}]
]
}],
["accordion", {
text: _("export"),
children: [
["title", {
titleSize: 3,
text: _("titleExport")
}],
["div", {
name: ID_CHART_ACTION_export_total,
cssClass: CHART_H
}],
["title", {
titleSize: 3,
text: _("titleExportAvg")
}],
["div", {
name: ID_CHART_ACTION_export_average,
cssClass: CHART_H
}]
]
}]
]
}]
]
}],
["tab", {
children: [
["title", {
titleSize: 3,
text: _("titleUser")
}],
["div", {
name: ID_CHART_USERS,
cssClass: CHART_H,
cssStyle: {
height: "500px"
}
}]
]
}]
]
}]
]
}]
];
[^] # Re: la vraie nouveauté
Posté par TImaniac (site web personnel) . Évalué à 5.
Parcqu'en C, java & co l'éditeur peut se baser justement sur les {} pour faire l'indentation, en Python, y'a aucun indice pour lui dire comment indenter au risque de péter la sémantique...
[^] # Re: la vraie nouveauté
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Parce qu'il n'y a rien dans la syntaxe python pour déterminer explicitement le début et la fin d'un bloc. Donc du coup, un "beautifier" de code serait infoutu de reindenter proprement du code python. Il pourrait tout de même se débrouiller avec la reconnaissance de certains mot clé. ex : tout ce qui se trouve entre deux mots clé def fait forcément partie du def (bon, mes connaissances rudimentaires en python ne me permettent pas de savoir si cette affirmation est vrai, mais tu vois le genre quoi).
[^] # Re: la vraie nouveauté
Posté par Victor STINNER (site web personnel) . Évalué à 9.
Un automate peut quand même facilement les trouver. Python y arrive bien ;-)
[^] # Re: la vraie nouveauté
Posté par smc . Évalué à 2.
En ce qui concerne les indentations en Python, on aime ou on aime pas, ça a des avantages et des inconvénients, mais le jour où on l'enlève Python sera plus vraiment Python.
[^] # Re: la vraie nouveauté
Posté par Thomas Douillard . Évalué à 6.
Faut juste que ton beautifier soit suffisamment malin pour reconnaître quel blocs sont "fils" de quel autre bloc, ce que l'interpréteur python arrive très bien à faire, et qui n'est pas si compliqué.
[^] # Re: la vraie nouveauté
Posté par manatlan (site web personnel) . Évalué à 2.
?!?
et le ":" ?
quand il y a un ":" en fin de ligne, les lignes suivantes n'auront pas la même indent ... jusqu'à qu'on change d'indentation inférieure.
[^] # Re: la vraie nouveauté
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Tu peux tronquer les lignes trop longues, je vois pas le rapport avec l'indentation. Tu coupes là où tu veux et tu mets « \ » en fin de ligne (souvent, même pas besoin de l'antislash). Je ne connais pas d'outil pour ça, mais en même temps je n'ai jamais lu de tel code (mais vu le nombre de légendes, ça doit exister :-)). Je pense qu'il existe des outils pour faire ça.
Pour uniformiser espaces et tabulations, Python intègre l'outil tabnanny.
Le jours ou tu voudra rajouter une condition, tu vas sélectionner un paquet de ligne indenter, et au passage oublier une ligne...
Je pense qu'un bon éditeur Python sait trouver la fin d'un bloc. Perso je le fais à la main avec vim : sélection des lignes à indenter puis commande < ou >.
Bien sûr, si le bloc fait 934 lignes, c'est plus dur. Mais là il faudrait penser à nettoyer un peu le code :-)
[^] # Re: la vraie nouveauté
Posté par Sisyphe Plâtrier . Évalué à 2.
devrait permettre de faire face, même à des blocs longs.
[^] # Re: la vraie nouveauté
Posté par Bozo_le_clown . Évalué à 2.
mais pour ne pas lancer de troll
Trop tard
http://use.perl.org/~Ovid/journal/38010
[^] # Re: la vraie nouveauté
Posté par ciol13 . Évalué à 3.
Par exemple pour un copier/coller c'est pas pratique, parfois ça fait foirer l'indentation.
Avec des accolades c'est plus robuste, même si tout est sur une seule ligne, tu perds pas le sens du programme.
[^] # Re: la vraie nouveauté
Posté par B16F4RV4RD1N . Évalué à 3.
J'aime bien le code propre et bien indenté pour la lisibilité.
Par contre dès que tu dois récupérer un extrait de code python sur internet, c'est la galère pour le remettre de sorte que cela compile bien. Dès que tu travailles avec des éditeurs différents, l'indentation n'est plus la même, dès que tu travailles en groupe c'est pareil (cf. la remarque plus haut).
En plus avec des accolades, on voit mieux où cela démarre et s'arrête.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: la vraie nouveauté
Posté par CrEv (site web personnel) . Évalué à 8.
C'est pour ça que les tab sont intéressantes, car chacun peut y mettre la taille qu'il veut en présentation.
Et sinon, en général un replace suffit, genre un replace automatique à chaque ouverture / fermeture de fichier est assez sympa dans ce cas (outre les directives qu'on trouve au début / à la fin de certains fichiers pour indiquer à l'éditeur comment se comporter)
> travailles en groupe
Ben pourquoi ?
Jamais vous ne décidez de conventions ?
Car avec les acollades c'est pas vraiment mieux, si dans le même fichier on a :
if(.........) {[...]
}
if ( ....... ){
[...]
}
if ( ....... ){
[...]
}
c'est mal barré, et pourtant il y a des accolades...
> avec des accolades, on voit mieux où cela démarre et s'arrête
mouai, perso je ne lis jamais les accolades mais l'indentation, et ce quelque soit le langage
avec des accolades en fin de ligne lire du python ou du java c'est un peu pareil
Et avec des éditeurs bien fait (comme kwrite/kate de kde4) on voit très facilement l'enchainement des blocs sans avoir besoin de lire quoi que ce soit (et ça c'est bien)
Bon après, il y a aussi la façon ruby, avec des end (oui je sais, c'est pas le seul...) mais pareil, autant les occulter...
[^] # Re: la vraie nouveauté
Posté par freeze . Évalué à 3.
En python ... c'est juste pas possible.
Après c'est bien de vouloir coder avec vi, mais il y a des choses qui se font mieux avec un environnement complet (même si c'est encore mieux si on peut coder dans les deux sans rien casser)
[^] # Re: la vraie nouveauté
Posté par CrEv (site web personnel) . Évalué à 4.
C'est ça que je ne comprend pas. Il y a bien des règles, sinon l'interpréteur ne fonctionnerait pas, non ?
Donc s'il y a des règles il est possible d'avoir un formatteur et là c'est bon, non ?
> vouloir coder avec vi, mais il y a des choses qui se font mieux avec un environnement complet
C'est pour ça qu'emacs est le bien !
[^] # Re: la vraie nouveauté
Posté par claudex . Évalué à 4.
# Fonction factorielle en python--def factorielle(x):
----if x == 0:
------return 1
----else:
------return x * factorielle(x-1)
PS: Je suis pas arriver à faire les indentations, elles ne passaient pas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: la vraie nouveauté
Posté par 태 (site web personnel) . Évalué à 6.
Cela dit, sur des exemples simples (le factorielle), c'est facile (les lignes finissant par : impliquent une indentation, le else implique une dédentation), mais au delà, il faut comprendre le code :
if (x>1) {
x = x-1;
if (x>1) {
x = x-2;
else {
x = x-3;
Tu les rajoutes où les dédentations/accolades fermantes ?
[^] # Re: la vraie nouveauté
Posté par Dr BG (site web personnel) . Évalué à 7.
Ai-je bien résumé ce que les messieurs plus haut essayent de dire ?
[^] # Re: la vraie nouveauté
Posté par Yth (Mastodon) . Évalué à 3.
Tu peux flinguer complêtement ton indentation, et mettre ce que tu veux, tu repasses avec emacs derrière et il te remet tout comme tu l'as écrit là, bien indenté.
Comme quoi, c'possible, hein ?
Un exemple où ça ne marche pas est le suivant :
# Fonction factorielle en pythondef factorielle(x):
__if x == 0:
____r = 1
__else:
____r = x * factorielle(x-1)
__return r
Pour les deux dernières lignes, et elles uniquement, le return r pourrait être au même niveau d'indentation que la ligne au dessus, soit dans le else, ça aurait toujours du sens, pas le même...
Yth, complètement fan de l'indentation python, c'est génial.
[^] # Re: la vraie nouveauté
Posté par Gniarf . Évalué à 3.
et effectivement de l'information aussi intangible, ou peu visible, je comprends que certains râlent.
[^] # Re: la vraie nouveauté
Posté par Bozo_le_clown . Évalué à 4.
- qu'on évite de taper 2 signe cabalistiques qui demandent des contorsions des doigts pour les entrer sauf à passer en qwerty ou pire des mots clé,
- qu'on a pas besoin d'avoir recours à des usines à gaz d'IDE pour gagner du temps à les taper
- qu'on n'a pas besoin de s'habituer aux conventions d' de chaque projet sur lequel on bosse pour décoder
- qu'un code 2 fois plus court est plus facile à déchiffrer
- qu'un code est indenté de façon homogène sans être obligé de rajouter une cible dans un build
- qu'on gagne du temps lorsqu'on lance un l'interprète en interactif
...
et effectivement de l'information aussi concise, et pratique, je comprends que certains adorent .
[^] # Re: la vraie nouveauté
Posté par Yth (Mastodon) . Évalué à 4.
Je ne suis pas d'accord, l'indentation c'est au contraire tout ce qu'on voit, directement et rapidement.
Va trouver l'accolade ouvrante correspondant à l'accolade fermante que tu regardes sans un éditeur qui te la montre quand tu es dessus ?
Si tu n'indentes pas correctement ton code, tu es parfois obligé de recompter tes accolades, et dans le genre chiant, c'est pas mal...
Par contre, si tu n'es pas prévenu à l'avance, et que tu ne fais pas attention, c'est sûr, tu vas te planter avec la mode python. Mais c'est uniquement parce que c'est inhabituel, différent des autres.
Yth, toujours aussi fan de l'indentation python :)
[^] # Re: la vraie nouveauté
Posté par Bozo_le_clown . Évalué à 4.
Je bosse en ce moment sur Java avec Eclipse pour reprendre le code d'un autre et je suis tjs en train de chercher l'accolade qui va bien.
Être obligé de se placer dessus l'ouvrante pour voir à quelle fermante elle correspond. Il doit surement y' avoir un raccourci qui "enlarge my productivity" mais mes 3 neurones peuvent pas tous les retenir
Bozo le clown, toujours aussi interloqué de voir Yth signer ses posts :D
[^] # Re: la vraie nouveauté
Posté par freeze . Évalué à 0.
Quelle règle peut suivre emacs ? aucune.
Avec des accolades, l'indentation apporte du confort.
Sans les accolades, l'indentation fait tout ... donc si elle est foireuse, tant pis, ça bug
[^] # Re: la vraie nouveauté
Posté par Bozo_le_clown . Évalué à 4.
En python ... c'est juste pas possible.
http://pydev.sourceforge.net/features.htm
Smart indentation (indent and dedent)l
... non, rien
[^] # Re: la vraie nouveauté
Posté par Bozo_le_clown . Évalué à 1.
http://www.netbeans.org/features/python/index.html
[^] # Re: la vraie nouveauté
Posté par Octabrain . Évalué à 4.
[^] # Re: la vraie nouveauté
Posté par Bozo_le_clown . Évalué à 4.
Tu demanderais pas à ton indenteur de te remettre le bon nombre d'accolade quand tu l'as foiré en rajoutant un bloc.
.
[^] # Re: la vraie nouveauté
Posté par Sisyphe Plâtrier . Évalué à 1.
[^] # Re: la vraie nouveauté
Posté par lolop (site web personnel) . Évalué à 6.
En Python, c'est juste pas nécessaire. Tu dois faire propre dès le début. Les étudiants s'y mettent sans problème, donc ça ne doit pas en être un (à part pour les informaticiens qui ont leurs habitudes).
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: la vraie nouveauté
Posté par olympi . Évalué à 3.
[^] # Re: la vraie nouveauté
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: la vraie nouveauté
Posté par olympi . Évalué à 1.
# Raisons?
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
Certains changement me semblent en effet très intéressant (notamment la séparation plus rationnelle des strings en "text" et "bytes") et permettent d'éviter de se planter silencieusement (donc sans que le dev en soit nécessairement conscient).
Par contre, des changements comme le bête print me semble injustifié. Certes, c'est plus logique mais garder un simple statement print n'aurait rien coûté et le coût de la migration me semble disproportionné par rapport au gain. Les changements dans les dict me semblent également important (sans compter qu'il va falloir réécrire toute la doc).
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Raisons?
Posté par Dufréchou Laurent . Évalué à 5.
Tu as un script tout bête dans lequel tu as fais des print pour debuguer:
print "hello"
...
print "done"
Hé bien, qd ton script est ok, tu devais commenter tout les scripts un à un.
Maintenant tu _dois_ (pas testé) pouvoir faire:
def myprint(...):
log to a file or do nothing
print = myprint
Et hop ca marche alors qu'avant tu ne pouviat pas faire ca, et pour arriver au meme point tu definissais une fonction log() qui remplacait le print...
Enfin je pense que c'est pour ca... je suis pas un expert.
[^] # Re: Raisons?
Posté par herodiade . Évalué à 8.
Les justifications sont dans les PEP :
http://www.python.org/dev/peps/pep-3105/
http://www.python.org/dev/peps/pep-3108/
etc.
> Par contre, des changements comme le bête print me semble injustifié. Certes, c'est plus logique mais garder un simple statement print n'aurait rien coûté et le coût de la migration me semble disproportionné par rapport au gain.
Le changement sur print() semble assez arbitraire, mais le coût de la migration est assez faible en fait : ils fournissent un script appelé 2to3 qui sait convertir ton code automatiquement (et les changements sont backward compatibles, la syntaxe print() est supportée dans les versions précédentes de python). Pour le reste je n'ai pas d'opinion.
[^] # Re: Raisons?
Posté par Victor STINNER (site web personnel) . Évalué à 5.
La syntaxe « print >>sys.stderr, "bla" » était un cas très particulier en Python : seul print utilise cette syntaxe. Maintenant la syntaxe est uniforme : « print("bla", file=sys.stderr) ».
Le mot clé print empêchait de définir une méthode print dans une classe.
print ("a", "b") prêtait à confusion : c'est un tuple de deux valeurs ou deux valeurs ? (afficher "a b" ou "('a', 'b')" ?) Avec Python3, il n'y a plus de doute possible.
print n'était qu'une longue liste de cas particuliers foireux.
[^] # Re: Raisons?
Posté par Gniarf . Évalué à 2.
[^] # Re: Raisons?
Posté par Larry Cow . Évalué à 2.
En même temps, il n'y avait confusion qu'à cause de la notation "future". On en serait resté exclusivement à l'ancienne syntaxe, ça n'aurait pas posé de problème.
[^] # Re: Raisons?
Posté par Victor STINNER (site web personnel) . Évalué à 8.
>>> print "a", "b"
a b
>>> print ("a", "b")
('a', 'b')
Je trouve ça moche : selon la présence de parenthèse ou non, le résultat est différent. Alors qu'habituellement, rajouter des parenthèses ne change rien. Exemple : « x = 1, 2 » et « x = (1, 2) » sont synonymes.
Ton argument est « avant c'était bogué, il faut que ça reste bogué ». Ça me fait penser aux bugs HTML d'Internet Explorer... Justement, Python3 fait table rase de vieilles horreurs pour homogénéiser le langage.
[^] # Re: Raisons?
Posté par abramov_MS . Évalué à 2.
[^] # Re: Raisons?
Posté par ribwund . Évalué à 4.
Sinon pour la migration, par exemple le print, tout est pris en charge par l'outil 2to3.py.
[^] # Re: Raisons?
Posté par Antoine . Évalué à 2.
Ce n'est pas du tout injustifié. Le fait que print devienne une fonction comme une autre veut dire qu'on peut le passer en paramètre, ou au contraire le remplacer par autre chose, comme pour toute fonction en Python.
Du reste, c'est un des changements les plus simples à assimiler dans Python 3.
# Tester la version 2.6 ou 3000 ?
Posté par PuRPLeHaZe . Évalué à 2.
Pour l'instant j'ai trouvée cette methode, mais elle est plutôt compliquée justement :
http://blog.pythonaro.com/2008/10/horrible-hack-to-get-pytho(...)
Je n'ai pas encore pris le temps de tester.
N'y a-t-il pas plus simple? Comment faites-vous ?
Juste dans l'objectif de tester la bête, une installation "en statique" à l'instar de celle que peuvent bénéficier les utilisateurs windows serait bien pratique.
[^] # Re: Tester la version 2.6 ou 3000 ?
Posté par PuRPLeHaZe . Évalué à 1.
[^] # Re: Tester la version 2.6 ou 3000 ?
Posté par PuRPLeHaZe . Évalué à 2.
Installer les librairies de développement :
apt-get install build-essential libncursesw5-dev libreadline5-dev libssl-dev libgdbm-dev libbz2-dev libc6-dev libsqlite3-dev tk-dev
Créer le répertoire d'installation : (pertinence ?)
cd /usr/lib
mkdir python3.0
Configuration, test (optionnel) et installation :
./configure --prefix=/usr/lib/python3.0
make
make test
make altinstall
[^] # Re: Tester la version 2.6 ou 3000 ?
Posté par 태 (site web personnel) . Évalué à 4.
[^] # Re: Tester la version 2.6 ou 3000 ?
Posté par PuRPLeHaZe . Évalué à 1.
Macports? Mais voilà qui est intéressant! Je ne connais pas. En cherchant un peu sur google, j'apprends qu'il s'agit d'un logiciel qui vise à faciliter l'installation de programmes X11 sur MacOSX. Cela s'utilise aussi sur debian?
[^] # Re: Tester la version 2.6 ou 3000 ?
Posté par 태 (site web personnel) . Évalué à 3.
Pour Macports, c'est un gestionnaire de paquets, pas juste pour des programmes X11, mais pour tout ce qui vient du monde unix en général. (la page d'accueil dit command-line, X11 and Aqua software). On peut l'installer à peu près n'importe où à condition d'avoir gcc, tcl et objc. Par contre, il faut le compiler si on n'est pas sous macosx. Dernière remarque, comme gentoo portage ou pkgsrc, macports fonctionne essentiellement sans utiliser de paquets binaires mais en compilant lui-même ce qu'il faut.
[^] # Re: Tester la version 2.6 ou 3000 ?
Posté par Victor STINNER (site web personnel) . Évalué à 3.
[^] # Re: Tester la version 2.6 ou 3000 ?
Posté par dab . Évalué à 1.
[^] # Re: Tester la version 2.6 ou 3000 ?
Posté par ciol13 . Évalué à 0.
Pour désinstaller il suffit de supprimer ce répertoire.
Alors que si tu configures avec --prefix=/usr/local, tu vas avoir tes fichiers pythons répartis dans plusieurs répertoires au sein de /usr/local
Mais après tu fais ce que tu veux.
Tu peux tout mettre dans /usr/local/lib/python26 si tu veux.
[^] # Re: Tester la version 2.6 ou 3000 ?
Posté par dab . Évalué à -1.
# Ajout d'un nouveau troll
Posté par Nicolas Évrard (site web personnel) . Évalué à 6.
def tu_vas_me_haïr():
œ = "J'écris les caractères que je veux et toi petit codeur américain tu râles"
œ += " autant que je peux râler quand je vois que tu n'as pas tenu compte des"
œ += " langues avec des accents."
print(œ)
tu_vas_me_haïr()
[^] # Re: Ajout d'un nouveau troll
Posté par Antoine . Évalué à 2.
En effet, c'est difficilement justifiable pour des langues faciles à translittérer (lorsqu'il s'agit juste de remplacer "ï" par "i" et "é" par "e" par exemple), ou pour des projets internationaux.
La demande, si je me souviens bien, vient d'utilisateurs japonais qui utilisent Python comme langage avec des utilisateurs peu anglophones qui veulent écrire des identifiants dans leur langue maternelle. Là ça change tout.
(il y a aussi le fait que Python est pas mal utilisé dans l'éducation)
[^] # Re: Ajout d'un nouveau troll
Posté par Maclag . Évalué à 4.
Et comme c'est de l'opensource, on peut laisser les développeurs du monde entier se plonger dedans dans l'espoir que quelqu'un soit assez polyglotte pour comprendre tout ce que ce bordel fait...
Et vive le vendredi!!
[^] # Re: Ajout d'un nouveau troll
Posté par BAud (site web personnel) . Évalué à 4.
et pourtant... le libre m'a permis de savoir que je comprenais un mot sur 5 en polonais, consolider mon espagnol, comprendre que l'allemand n'était pas fait pour moi (je réponds en anglais), désespérer des kikoolol non seulement en français mais en algérien ou russe aussi :/
bref, une ouverture sur le monde, vive le libre, vive Internet, cela demande clairement de prendre sur soi mais il y a effectivement des limites /o\
Et c'est là qu'il faut dire : vive l'esperanto qui présente le même degré de difficulté (ou plutôt de facilité pour chacun), c'est vendredi hein :D
[^] # Re: Ajout d'un nouveau troll
Posté par Antoine . Évalué à 4.
Oui, parce qu'avant que Python n'autorise les identifiants non-ASCII les développeurs du monde entier parlaient tous parfaitement anglais et n'utilisaient jamais une autre langue. On n'avait jamais vu un programme utiliser des identifiants et des commentaires non anglais, et voilà que l'horrible Guido van Rossum ouvre la boîte de Pandore.
Le responsable d'un problème est donc celui qui tente d'y apporter une solution au lieu de le balayer sous le tapis en regardant ailleurs. Bientôt on saura que les bugs trackers sont les vrais responsables de l'existence des bugs.
on peut laisser les développeurs du monde entier se plonger dedans dans l'espoir que quelqu'un soit assez polyglotte pour comprendre tout ce que ce bordel fait...
La tour de Babel c'est pas très nouveau, ça date même d'avant l'informatique. Qu'est-ce que tu redécouvres au prochain message ?
[^] # Re: Ajout d'un nouveau troll
Posté par lolop (site web personnel) . Évalué à 2.
* certains en ont vraiment besoin (formation dans des langues non latines, identificateurs mappant des noms de colonnes avec des caractères non ascii...),
* les projets libres resteront avec les a-z standards et des identificateurs anglais, simplement parce qu'ils n'ont pas le choix s'ils veulent que tout le monde puisse y accéder (et les développeurs de nouveaux projets, s'ils comptent l'ouvrir à l'extérieur, feront de même),
* rien ne m'oblige à utiliser des éàçû dans mes identificateurs.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Ajout d'un nouveau troll
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
L'ascii n'a plus aucune raison d'être et doit disparaître. Un codage sur 7 bit ! Pourquoi ne pas encoder l'année sur 2 entiers au l ieu de 4 pour gagner de la place tant qu'on y est ?
L'UTF-8 a tendance à se généraliser et devrait être partout, plus rien ne justifie des économies d'octets.
J'ai travaillé sur un code Japonais en C. Pour une raison que j'ignore, les japonais ont décidé d'utiliser une locale très très particulière et qui est compliquée à installer. Le japonais n'est utilisé que dans les commentaires mais si tu as le malheur de modifier un commentaire, le code ne compile plus !!! (et oui). Tout simplement à cause des foutus encodages de caractères. (J'ai écrit un script qui traduit tout en UTF-8, ça ne compile plus non plus, ce truc est à la limite du surnaturel).
Alors je peux te jurer que l'idée d'unifier l'encodage de caractère me semble relativement bonne...
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Ajout d'un nouveau troll
Posté par Larry Cow . Évalué à 3.
[^] # Re: Ajout d'un nouveau troll
Posté par Victor STINNER (site web personnel) . Évalué à 3.
[^] # Re: Ajout d'un nouveau troll
Posté par dab . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.