Author serhiy.storchaka
Recipients benjamin.peterson, brett.cannon, gvanrossum, nascheme, ncoghlan, serhiy.storchaka, vstinner, yselivanov
Date 2018-09-21.20:59:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> Can you describe what usages of the old API will continue to work, and what part will break?

Very good question!

What will continue to work:

* Instantiating. Both `Num(42)` and `Num(n=42)` will continue to work, but they will return an instance of Constant: Constant(value=42).

* Attribute access. Constant will get attributes "n" and "s" as aliases to the attribute "value". So Num(42).n will continue to return 42. 

* isinstance() check. Although `isinstance(Num(42), Num)` will continue to return True, and `isinstance(Str('42'), Num)` will continue to return False. Also `isinstance(Constant(42), Num)` will return True and `isinstance(Constant('42'), Num)` will return False.

* Subclassing. Subclasses of these classes will continue to behave as normal classes. Instantiating them will return instances of that classes, not Constant, and the isinstance() check will not have any magic.

What will no longer work:

* issubclass() check and exact type check. `issubclass(type(node), Num)` and `type(node) is Num` will return False for node = Num(42). But seems isinstance() is a more common way of checking the type of a node.

* If the user of NodeVisitor implemented visit_Num(), but not implemented visit_Constant(), his handler will not be triggered. This can be easily fixed by implementing visit_Constant(). Constant was introduced in 3.6.

* isinstance() check for underinitialized node. `isinstance(Num(), Num)` will return False.
Date User Action Args
2018-09-21 20:59:34serhiy.storchakasetrecipients: + serhiy.storchaka, gvanrossum, brett.cannon, nascheme, ncoghlan, vstinner, benjamin.peterson, yselivanov
2018-09-21 20:59:34serhiy.storchakasetmessageid: <>
2018-09-21 20:59:34serhiy.storchakalinkissue32892 messages
2018-09-21 20:59:34serhiy.storchakacreate