Changements de Python 2 à Python 3.0

en premier

Cet article est l'article du 9ème jour du Calendrier de l'Avent Python Partie 2 2015.

J'ai décidé d'écrire

J'ai écrit Python pour la première fois il y a quatre ans et j'ai pensé que c'était un très bon langage, donc j'ai toujours écrit du code simple en Python. La première chose que j'ai écrite était Python 2.7, mais quand je l'ai étudié, il y avait quelque chose qui s'appelait Python 3, et j'aimais les nouvelles choses, donc quand j'ai vraiment commencé à apprendre, j'ai utilisé Python 3.3. Donc, je ne savais pas grand chose sur le 2ème système, et je ne pensais pas qu'il était nécessaire d'apprendre les anciens (bien que le 2ème système était le principal à l'époque). Mais. Il y avait divers problèmes tels que la bibliothèque de 2 séries ne supportait pas 3 séries, et elle a été écrite en 2 séries et j'ai dû la remplacer par 3 séries par moi-même.

Quoi qu'il en soit, j'ai décidé de jeter un coup d'œil aux différences entre les 2e et 3e systèmes tout en apprenant. (Mis à part le fait que cela fait environ 7 ans que le 3ème système est sorti ...) (De plus, mis à part le fait que d'autres personnes formidables écrivent de merveilleux articles ... (T_T))

Avant d'entrer dans le sujet principal ...

――Lorsque j'ai commencé à écrire, je pensais que j'écrirais la progression de Python2 à Python3.5, mais comme elle est devenue assez longue jusqu'à Python3.0, la progression de Python3.0 à Python3.5 est un article séparé. Inscrire.

• La version dans laquelle vous avez exécuté le code est écrite en haut à gauche.
• Pour ceux qui ont une certaine connaissance de Python. Si vous l'avez un peu touché, ça va probablement!
• Le trait de soulignement qui apparaît soudainement dans le code stocke le résultat de l'exécution précédente.

Python3

>>> 1+1
2
>>> _
2
>>> 2+3
5
>>> _ -3
2
>>> type(_)
<class 'int'>
>>> _
<class 'int'>

Eh bien, c'est assez long (rires) Faisons de notre mieux!

Python2 -> Python3.0

imprimer les modifications d'une instruction à l'autre

Python2

>>> print 'Hello'
Hello

Python3

>>> print('Hello')
Hello

La définition en Python3 semble être comme ça.

def print(*args, sep=' ', end='\n', file=None)

Je me demande si j'ai des problèmes en essayant d'afficher le taple.

Python2

>>> print ('item1', 'item2')
('item1', 'item2')

Python3

>>> print ('item1', 'item2')
item1 item2
>>> print(('item1', 'item2'), )
('item1', 'item2')

Renvoie des vues et des itérateurs au lieu de listes

Vues est Nanno Kocha. Eh bien, vous pouvez voir le résultat.

méthodes dict, clés, éléments, valeurs retournent des vues

Python2

>>> d = {"key1": "value1"}
>>> d.keys()
['key1']
>>> type(_)
<type 'list'>
>>> d.values()
['value1']
>>> d.items()
[('key1', 'value1')]

Python3

>>> d = {"key1": "value1"}
>>> d.keys()
<dict_keys object at 0x7f0da5268e18>
>>> type(_)
<class 'dict_keys'>
>>> d.values()
<dict_values object at 0x7f0da5268e18>
>>> d.items()
<dict_items object at 0x7f0da3a44638>

En Python2, tout est une liste, et en Python3, il est renvoyé sous la forme d'un objet tel que dict_keys. C'est un objet itérable, que vous appelez probablement Views.

Si vous le souhaitez sous forme de liste en Python3, enveloppez-le avec list ().

Python3

>>> list(d.keys())
['key1']

Suppression des méthodes dict, iterkeys, iteritems, itervalues

Python2

>>> d.iterkeys()
<dictionary-keyiterator object at 0x7f5b586155d0>
>>> type(_)
<type 'dictionary-keyiterator'>

Python3

>>> d.iterkeys()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'dict' object has no attribute 'iterkeys'

C'est naturel, non? Les clés renvoient l'itérateur.

map, la fonction de filtrage renvoie un itérateur

Python2

>>> f1 = lambda x : x + 1
>>> f2 = lambda x : x%2 == 0
>>> l = [1, 2, 3]
>>> map(f1, l)
[2, 3, 4]
>>> type(_)
<type 'list'>
>>> filter(f2, l)
[2]
>>> type(_)
<type 'list'>

Python3

>>> iter_check = lambda obj : hasattr(obj, '__iter__') and hasattr(obj, '__next__')
>>> isIterable = lambda obj : hasattr(obj, '__iter__')
>>> f1 = lambda x : x + 1
>>> f2 = lambda x : x%2 == 0
>>> l = [1, 2, 3]
>>> map(f1, l)
<map object at 0x7f0da5261950>
>>> map_obj = _
>>> type(map_obj)
<class 'map'>
>>> iter_check(map_obj)
True
>>>
>>> filter(f2, l)
<filter object at 0x7f0da52619d0>
>>> filter_obj = _
>>> type(filter_obj)
<class 'filter'>
>>> iter_check(filter_obj)
True

Vous n'avez pas à vous soucier trop du contenu du lambda (rires) C'est une fonction pour vérifier s'il s'agit d'un objet itérable ou d'un itérateur. Une liste est renvoyée en Python2 et un itérateur est renvoyé en Python3.

La fonction range Python3 renvoie un objet itérateur (xrange en Python2). xrange est aboli

Python2

>>> iter_check = lambda obj : hasattr(obj, '__iter__') and hasattr(obj, '__next__')
>>> isIterable = lambda obj : hasattr(obj, '__iter__')
>>> type(range(1,10))
<type 'list'>
>>> type(xrange(1,10))
<type 'xrange'>
>>> iter_check(xrange(1,10))
False
>>> isIterable(xrange(1,10))
True

Python3

>>> type(range(1,10))
<class 'range'>
>>> type(iter(range(1,10)))
<class 'range_iterator'>
>>> xrange(1,10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'xrange' is not defined

Dans Python 3, range renvoie un objet itérable au lieu d'une liste. Et xrange est décédé. Chaîne

la fonction zip renvoie un itérateur

Python2

>>> zip([1,2,3], [2,3,4])
[(1, 2), (2, 3), (3, 4)]
>>> type(_)
<type 'list'>

Python3

>>> zip([1,2,3], [2,3,4])
<zip object at 0x7f0da3a40cf8>
>>> iter_check(_)
True

Python3 renvoie un itérateur.

Comparaison des commandes

L'opérateur de comparaison (<,>, <=,> =) renvoie une TypeError si ses opérandes n'ont pas d'ordre naturel.

Python2

>>> 1 < 'a'
True
>>> 0 > None
True
>>> len <= len
True
>>> None < None
False

Python3

>>> 1 < 'a'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: int() < str()
>>> 0 > None
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: int() > NoneType()
>>> len <= len
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: builtin_function_or_method() <= builtin_function_or_method()
>>> None < None
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: NoneType() < NoneType()

Je le savais pour la première fois. Python2 est terrible ... Cependant, Python3 lève fermement les exceptions, donc c'est sûr!

La fonction triée et la méthode de tri de la liste ne prennent plus l'argument cmp qui donne une fonction de comparaison

La définition dans Python 2 est la suivante sorted(iterable[, cmp[, key[, reverse]]]) s.sort([cmp[, key[, reverse]]])

La définition dans Python 3 est la suivante sorted(iterable[, key][, reverse]) sort(*, key=None, reverse=None)

L'argument cmp a disparu. De plus, l'argument de la méthode de tri de la liste en Python3 doit être passé comme argument mot-clé.

La fonction cmp est obsolète et la méthode __cmp__ n'est plus prise en charge

Ce n'est pas un exemple, n'est-ce pas? Veuillez utiliser la méthode __lt__ pour le tri.

À propos des entiers

Fondamentalement, long a été renommé en int (mais se comporte comme l'ancien type long)

Python2

>>> type(10**100)
<type 'long'>

Python3

>>> type(10**100)
<class 'int'>

Il est traité comme un type int en Python.

Les expressions telles que 1/2 renvoient un type float. Lorsque vous tronquez moins de quelques points, utilisez une expression telle que 1/2/2

Python2

>>> 1/2
0
>>> type(1/2)
<type 'int'>

Python3

>>> type(1/2)
<class 'float'>
>>> 1//2
0
>>> type(1//2)
<class 'int'>

Si vous souhaitez diviser avec Python3 et retourner avec int, utilisez l'opérateur //.

La constante sys.maxint a été supprimée car il n'y a pas de limite supérieure sur les entiers

Python2

>>> sys.maxint
9223372036854775807

Python3

>>> sys.maxint
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'maxint'

Il a été supprimé.

La méthode de reprographie en entier long ne se termine pas par L

Python2

>>> 10**20
100000000000000000000L

Python3

>>> 10**20
100000000000000000000

L n'est pas à la fin dans Python3.

Le littéral huit-aires est passé d'une notation comme 0720 à une notation comme 0o720

Python2

>>> 0720
464
>>> 0o720
464

Python3

>>> 0720
  File "<stdin>", line 1
    0720
       ^
SyntaxError: invalid token
>>> 0o720
464

Est-ce une forme unifiée pour les notations telles que 0x et 0b?

Vers du texte et des données au lieu d'unicode et 8 bits

Tout le texte en Unicode

Comme le dit le titre. Cela a rendu le texte Unicode précédent littéral ʻu "..." `inutilisable.

Python2

>>> u"unicode"
u'unicode'

Python3

>>> u"unicode"
  File "<stdin>", line 1
    u"unicode"
             ^
SyntaxError: invalid syntax

Le texte est de type str, les données sont de type octets

Python3

>>> type("test")
<class 'str'>
>>> type(b"test")
<class 'bytes'>

Utilisez b" ... " pour les littéraux de données binaires.

Envoyer TypeError lors du mélange de texte et de données

Python2

>>> "str" + b"bytes"
'strbytes'

Python3

>>> "str" + b"bytes"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Can't convert 'bytes' object to str implicitly

Python2 Sérieusement ... (2ème fois) C'est une chose tellement folle. .. Python3 est faux!

Conversion explicite entre texte et données

Python3

>>> "str".encode()
b'str'
>>> bytes("str", "utf-8")
b'str'
>>> 
>>> b"bytes".decode()
'bytes'
>>> str(b"bytes", "utf-8")
'bytes'

C'est une conversion entre str et bytes. Eh bien, il existe de nombreux articles sur l'encodage et le décodage en Python, alors veuillez vous y référer.

Les backslashes sont interprétés tels quels dans les chaînes brutes

Python2

>>> print(ur"\u20ac")
€

Python3

>>> print(r"\u20ac")
\u20ac

Je ne dis pas que Python2 est sérieux, mais bon! C'est un sentiment. Je n'aime pas les cordes brutes! Eh bien, il peut y avoir des moments où vous voulez ce comportement, mais le comportement de Python 3 est meilleur.

Suppression de la classe abstraite appelée basestring

Python2

>>> str.__base__
<type 'basestring'>
>>> bytes.__base__
<type 'basestring'>

Python3

>>> str.__base__
<class 'object'>
>>> bytes.__base__
<class 'object'>

En Python2, il y avait une classe abstraite appelée basestring. Cela signifie que le type str et bytes a été créé en l'héritant. En Python3, chaque classe est définie directement.

Résumé des changements de syntaxe

Ajouter une annotation de fonction

Python3

>>> def f(a: "int_value", b: "int_value default value one" = 1) -> "added_value":
...   return a+b
... 
>>> f.__annotations__
{'a': 'int_value', 'b': 'int_value default value one', 'return': 'added_value'}

Vous pouvez ajouter des annotations aux arguments de fonction et aux valeurs de retour. Dans l'exemple ci-dessus, il ne s'agit que d'une chaîne de caractères, mais comme vous pouvez écrire une expression, vous pouvez écrire «1 + 1», «int », etc.

Python3

>>> i=2
>>> j=3
>>> def f(a: i*j, b: i+j) -> 1+1:
...  return a+b
... 
>>> f.__annotations__
{'a': 6, 'b': 5, 'return': 2}
>>> i=10
>>> j=10
>>> f.__annotations__
{'a': 6, 'b': 5, 'return': 2}

L'expression est évaluée lorsque la fonction est définie. C'est naturel, non? ..

Arguments de mots clés uniquement

Python3

>>> def f(a, *, b):
...   return a+b
... 
>>> def g(*, a, b):
...   return a*b
... 
>>> f(1, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: f() takes exactly 1 positional argument (2 given)
>>> f(1, b=2)
3
>>> g(1, b=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: g() takes exactly 0 non-keyword positional arguments (1 given)
>>> g(a=1, b=2)
2
>>> g(b=1, a=2)
2

Vous pouvez utiliser l'astérisque «*» pour limiter les arguments listés après cela aux arguments de mot-clé. Il y a très peu de documents japonais, donc quand je l'ai vu pour la première fois, j'étais en difficulté (rires).

Vous pouvez passer des arguments de mot-clé après la liste des classes de base dans la définition de classe

Python3

>>> class MClass(type):
...  def __new__(cls, name, bases, namespace, **kwds):
...   result = type.__new__(cls, name, bases, dict(namespace))
...   result.members = tuple(namespace)
...   return result
...  def __init__(self, *args, **kargs):
...   print("args: " + str(args))
...   print("kargs: " + str(kargs))
... 
>>> class A(object, metaclass=MClass, a=1, b=2, c=3):
...   def one(self): pass
... 
args: ('A', (<class 'object'>,), {'__module__': '__main__', 'one': <function one at 0x7f62d071c408>})
kargs: {'a': 1, 'c': 3, 'b': 2}

C'est un peu lourd ... Quoi qu'il en soit, vous pouvez recevoir des arguments de mot-clé après la classe de base. Cependant, type ne peut pas recevoir d'arguments de mots-clés, vous devez donc créer votre propre méta-classe pour pouvoir la recevoir. .. (MClass est ça)

déclaration non locale

Python3

>>> def counter(init=0):
...  def cntup():
...   nonlocal init
...   init+=1
...   return init
...  return cntup
...
>>> c = counter()
>>> c()
1
>>> c()
2
>>> c()
3

L'instruction non locale permet à l'identificateur spécifié de faire référence à une variable dans la portée supérieure suivante. Bref, est-ce une fermeture? Dans l'exemple, l'argument init de la fonction de compteur est référencé par une instruction non locale. En Python2, je ne pourrais pas le faire sans utiliser la liste, etc., mais en Python3, je peux l'écrire de manière concise. (Si vous voulez simplement y faire référence, vous n'avez pas besoin de liste non locale ou de liste en Python2. Vous en avez besoin lors de la liaison à des variables dans la portée externe.)

Python3

>>> c.__closure__
(<cell at 0x7f62d071d5c8: int object at 0x7a3e20>,)
>>> c.__closure__[0].cell_contents
3

En passant, vous pouvez vous référer à la fermeture de cette manière.

Déballage itérable étendu

Python3

>>> a, *rest, b = range(5)
>>> a
0
>>> rest
[1, 2, 3]
>>> b
4

Après avoir déballé a et b au repos, le surplus est déballé sous forme de liste. Ce reste peut être décompressé sous forme de liste vide.

Python3

>>> a, *rest, b = range(2)
>>> a
0
>>> rest
[]
>>> b
1

c'est incroyable···.

Syntaxe modifiée

Syntaxe de capture d'exception

Python2

>>> try:
...  raise Exception("test")
... except Exception, e:
...  print "catch exception!"
... 
catch exception!

Python3

>>> try:
...  raise Exception("test")
... except Exception as e:
...  print("catch exception!")
... 
catch exception!

La virgule a été remplacée par le mot-clé as.

Nouvelle syntaxe de l'instruction Lever

Python3

>>> try:
...  raise Exception("test")
... except Exception as e:
...  raise RuntimeError("catch exception!") from e
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
Exception: test

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
RuntimeError: catch exception!

La clause from a été ajoutée pour vous permettre de représenter une chaîne d'exceptions. En outre, cela semble fonctionner implicitement lorsqu'une exception est levée dans la clause except.

Python3

>>> try:
...  1/0
... except Exception as e:
...  raise RuntimeError("raise exception.")
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
ZeroDivisionError: int division or modulo by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
RuntimeError: raise exception.

True, False sont des mots réservés

Python2

>>> True = 0
>>> False = 1
>>> True
0
>>> False
1
>>> True and True
0

Python3

>>> True=0
  File "<stdin>", line 1
SyntaxError: assignment to keyword
>>> False=1
  File "<stdin>", line 1
SyntaxError: assignment to keyword

Horreur! !! Eh bien, vous pouvez le remplacer par True, False ou normalement! Je ne.

Modifications de la syntaxe de la métaclasse

Python2

>>> class M(type):
...  pass
... 
>>> class C:
...  __metaclass__ = M
... 
>>> C.__class__
<class '__main__.M'>

Python3

>>> class M(type):
...  pass
... 
>>> class C(metaclass=M):
...  pass
... 
>>> C.__class__
<class '__main__.M'>

Dans Python2, la variable \ _ \ _ metaclass \ _ \ _ est transmise, et dans Python3, la classe de base est spécifiée et transmise comme argument de mot-clé. Python3 ne prend pas en charge les méthodes telles que Python2.

Ce que j'ai appris pour la première fois ici, c'est qu'en Python2, la classe devait hériter explicitement d'un objet, mais en utilisant une métaclasse, une classe qui hérite d'un objet peut être créée. Je vois!

Python2

>>> class A:
...  pass
... 
>>> A.__bases__
()
>>> class C:
...  __metaclass__ = type
... 
>>> C.__bases__
(<type 'object'>,)

les points de suspension peuvent être utilisés comme une expression primitive n'importe où

Python3

>>> ...
Ellipsis
>>> def e():
...  ...

réduction. (Je n'ai rien à dire ...)

Opération supprimée

Il a été supprimé, alors passons à autre chose.

Déballage des arguments de tapple

Python2

>>> def foo(a, (b,c)):
...  return a+b+c
... 
>>> t = 2,3
>>> foo(1, t)
6

Python3

>>> def foo(a, (b,c)):
  File "<stdin>", line 1
    def foo(a, (b,c)):
               ^
SyntaxError: invalid syntax

C'est difficile à lire ... En Python3, je me fâche dès la première ligne.

À propos des citations de retour

Python2

>>> i = 123
>>> `i`
'123'

Python3

>>> i=123
>>> `i`
  File "<stdin>", line 1
    `i`
    ^
SyntaxError: invalid syntax

Apparemment, la méthode \ _ \ _ repr \ _ \ _ a été appelée.

À propos de l'exécutif

Python2

>>> exec "print('python2')"
python2
>>> exec("print('python2')")
python2

Python3

>>> exec "print('python3')"
  File "<stdin>", line 1
    exec "print('python3')"
                          ^
SyntaxError: invalid syntax
>>> exec("print('python3')")
python3

En Python2, c'était une instruction exec. La notation de fonction est également correcte. En Python3, ce n'est plus un mot réservé et reste en tant que fonction.

<> opérateur

Python2

>>> 1 <> 2
True
>>> 1 <> 1
False

Python3

>>> 1 <> 2
  File "<stdin>", line 1
    1 <> 2
       ^
SyntaxError: invalid syntax

! = N'est-ce pas correct?

Autour du littéral

Python2

>>> u"python2"
u'python2'
>>> 100L
100L

Python3

>>> u"python3"
  File "<stdin>", line 1
    u"python3"
             ^
SyntaxError: invalid syntax
>>> 100L
  File "<stdin>", line 1
    100L
       ^
SyntaxError: invalid syntax

C'est ce que j'ai déjà mentionné ci-dessus.

À propos de l'importation du module * autre que le niveau supérieur

Python2

>>> from sys import *
>>> def f():
...  from os import *
... 
<stdin>:1: SyntaxWarning: import * only allowed at module level

Python3

>>> from sys import *
>>> def f():
...  from os import *
... 
  File "<stdin>", line 1
SyntaxError: import * only allowed at module level

L'avertissement est devenu Erreur. Pourquoi Python 2 s'est-il arrêté avec Warning ...

Autres changements

Opérateurs et méthodes spéciales

! = Renvoie l'opposé de == (si == ne renvoie pas Non implémenté)

Python2

>>> class C:
...  def __init__(self, a):
...   self.a = a
...
...  def __eq__(self, other):
...   return self.a == other.a
...
>>> a = C(1)
>>> b = C(1)
>>> c = C(2)
>>> a == b
True
>>> a == c
False
>>> a != b
True
>>> a != c
True

Python3

>>> class C:
...  def __init__(self, a):
...   self.a = a
...
...  def __eq__(self, other):
...   return self.a == other.a
...
>>> a = C(1)
>>> b = C(1)
>>> c = C(2)
>>> a == b
True
>>> a != b
False
>>> a == c
False
>>> a != c
True

C'était un peu surprenant. Python2 ! = N'implémente pas __ne__ (), donc il compare si les objets sont identiques. Le résultat est Vrai car a, b et c sont tous différents. Je me demandais si j'obtiendrais une erreur d'attribut ... C'était une histoire que vous pouvez comprendre avec un peu de réflexion.

Des méthodes indépendantes à l'objet fonction

Python2

>>> class C:
...  def f(self):
...   pass
...
>>> C.f
<unbound method C.f>

Python3

>>> class C:
...  def f(self):
...   pass
...
>>> C.f
<function f at 0x100a35270>

Oui. Python3 est traité comme une simple fonction. La méthode indépendante est probablement une méthode qui n'est pas liée à une instance. Python3 est plus simple et plus facile à comprendre

Le type de méthode __getslice__ () est supprimé et l'objet slice est passé au type de méthode __getitem__ ().

Python2

>>> class C:
...  def __getslice__(self, i, j):
...   print i, j
...   raise NotImplementedError()
...
>>> a = C()
>>> a[0:2]
0 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in __getslice__
NotImplementedError

Python3

>>> class C:
...  def __getitem__(self, obj):
...   print(obj)
...   print(type(obj))
...   raise NotImplementedError()
...
>>> a = C()
>>> a[0:2]
slice(0, 2, None)
<class 'slice'>
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in __getitem__
NotImplementedError

• getslice
• setslice
• delslice

Mais

• getitem
• setitem
• delitem

Est maintenant appelé à la place, et les objets de tranche sont maintenant passés. Je ne l'ai pas implémenté dans l'exemple, mais vous pouvez voir que l'objet slice est passé en argument.

La méthode next () a été renommée __next__ ()

Python2

>>> class C:
...  def __iter__(self):
...   return self
...
...  def next(self):
...   return 0
...
>>> a = C()
>>> i = iter(a)
>>> next(i)
0
>>> i.next()
0

Python3

>>> class C:
...  def __iter__(self):
...   return self
...
...  def __next__(self):
...   return 0
...
>>> a = C()
>>> i = iter(a)
>>> next(a)
0
>>> i.__next__()
0

Il a changé pour que __next__ () soit appelé à partir de next ().

«oct ()» et «__hex __ ()» ont été supprimés et «index ()» doit être utilisé

Python2

>>> class C:
...  def __oct__(self):
...   return "07"
...
...  def __hex__(self):
...   return "0x7"
...
>>> a = C()
>>> hex(a)
'0x7'
>>> oct(a)
'07'

Python3

>>> class C:
...  def __index__(self):
...   return 7
...
>>> a = C()
>>> hex(a)
'0x7'
>>> oct(a)
'0o7'

__oct__ () et __hex __ () sont des méthodes qui convertissent un nombre en chaîne et le renvoient, mais __index__ () ne renvoie qu'un nombre. Après cela, Python le convertira en bon. Python3 est merveilleux ~. (L'exemple renvoie une constante, mais pardonnez-moi s'il vous plaît ...)

__nonzero__ () a été renommé __bool__ ()

Python2

>>> class C:
...  def __nonzero__(self):
...   return True
...
>>> a = C()
>>> bool(a)
True

Python3

>>> class C:
...  def __bool__(self):
...   return True
...
>>> a = C()
>>> bool(a)
True

Comment avez-vous choisi le nom «nonzero ()»? En Python 3, __bool__ () est appelé. Facile à comprendre.

Builtins

Ajout de super ()

Python3

>>> class SuperClass:
...  pass
... 
>>> class SubClass(SuperClass):
...  def findSuperClass(self):
...   print("call super(): ", super())
...   print("call super(SubClass, self)", super(SubClass, self))
...
>>> i = SubClass()
>>> i.findSuperClass()
call super():  <super: <class 'SubClass'>, <SubClass object>>
call super(SubClass, self) <super: <class 'SubClass'>, <SubClass object>>

super () peut être appelé sans argument et sélectionnera automatiquement la classe et l'instance appropriées pour vous. Le traitement est le même que lorsqu'il y a un argument.

Renomméraw_input ()en ʻinput ()`

Python3

>>> input()
test
'test'

ʻInput () lit une ligne à partir de l'entrée standard et renvoie la chaîne sans saut de ligne. Si vous voulez exécuter ʻinput () en Python2, vous pouvez le faire avec ʻeval (input ())`.

Résumé

En Python émoussé 3

--print devient une fonction La méthode --keys, items, values renvoie des objets itérables

• La chaîne standard est Unicode et le type est str --xrange devient range

Je pense qu'il n'y a presque aucun problème si vous vous souvenez de la région.

De plus, j'ai omis certains changements dans cet article, mais j'ai supprimé environ 10% du contenu de niche qui ne me semblait pas très important. Si vous voulez savoir, veuillez lire Quoi de neuf en Python 3.0 (round throw).

À la fin

Alors que j'écrivais l'article, j'ai été surpris de constater que Python2 était accro aux pièges. Je suis content d'avoir commencé à le faire moi-même à partir de Python 3 (rires)

Et si vous n'êtes pas encore passé de Python 2, il est pratique de profiter de cette occasion pour vous en souvenir et de passer à Python 3 et vous aurez une vie Python heureuse (rires). (Bien qu'il existe de nombreux articles de synthèse tels que Python 2 à 3)

Comme je l'ai écrit au début, j'écrirai la progression de Python 3.0 à Python 3.5 dans un autre article. La progression de Python 3.0 vers Python 3.5 aura lieu le 16 du calendrier de l'avent Python Part 2.

De plus, si vous avez des points ou des erreurs étranges, ou si vous pensez que c'est mieux, veuillez commenter!

Demain est gratuit et le 11 est @FGtatsuro!

** Alors ayez une bonne vie Python3! !! ** **