Hi zope developers! As you may know, python 3 introduced the concept of annotations for callable objects. That annotations store information about arguments and return values, which is kinda nice language feature that will allow us to do interesting things. But there's a problem: those annotations will be stored in object's __annotations__ attribute, which is also used by zope.annotation's AttributeAnnotation implementation, so they will conflict. I think that it's a good time now to start thinking about problems like this, because there's a lot of time before zope will be used in python 3.0, so we can prepare to move without much problems. So, I propose to change annotation storage attribute to "__zope_annotation__" and make AttributeAnnotation adapter automatically migrate data from __annotations__ to __zope_annotations__. I think that adding "zope" to the attribute name will avoid any name clashes in future. I'd like to hear about problems that this change can possibly introduce (__slots__, security proxies, etc.) and maybe some more community ideas on that. -- WBR, Dan Korostelev
On Mar 9, 2009, at 5:20 PM, Dan Korostelev wrote:
Hi zope developers!
As you may know, python 3 introduced the concept of annotations for callable objects. That annotations store information about arguments and return values, which is kinda nice language feature that will allow us to do interesting things.
But there's a problem: those annotations will be stored in object's __annotations__ attribute, which is also used by zope.annotation's AttributeAnnotation implementation, so they will conflict.
I think that it's a good time now to start thinking about problems like this, because there's a lot of time before zope will be used in python 3.0, so we can prepare to move without much problems.
So, I propose to change annotation storage attribute to "__zope_annotation__" and make AttributeAnnotation adapter automatically migrate data from __annotations__ to __zope_annotations__. I think that adding "zope" to the attribute name will avoid any name clashes in future.
I'd like to hear about problems that this change can possibly introduce (__slots__, security proxies, etc.) and maybe some more community ideas on that.
Hi Dan. Thanks for bringing this up. If we do make changes for this purpose, I'd like to no longer use the __*__ pattern. When Zope 3 used the pattern initially, Python was not clear on its usage. Since then, it has clearly stated that the language claims __*__. While your proposal (__zope_*__) would almost certainly avoid a clash, I'd prefer to stick to the letter of the (new) law. I'd prefer "_z_*" or "_zope_*" or "_z_*__" or some other variation. (The ZODB usues _p_*, of course; I am inclined to _z_* because of the parallel and because it is short.) (If you are interested in the Python "waffle" when Zope 3 was written and the current language reference/PEP 8 , see my blog post this from February: http://codesinger.blogspot.com/2009/02/dont-use-in-python-unless-you-are.htm... . It may come off more strongly than it should, but I still find the point to be a good one.) Gary
On Mon, Mar 9, 2009 at 6:01 PM, Gary Poster <gary.poster@gmail.com> wrote:
If we do make changes for this purpose, I'd like to no longer use the __*__ pattern.
+1 -- new or changed attributes should follow some other pattern -- Benji York Senior Software Engineer Zope Corporation
On Mon, Mar 9, 2009 at 22:20, Dan Korostelev <nadako@gmail.com> wrote:
As you may know, python 3 introduced the concept of annotations for callable objects. That annotations store information about arguments and return values, which is kinda nice language feature that will allow us to do interesting things.
But there's a problem: those annotations will be stored in object's __annotations__ attribute, which is also used by zope.annotation's AttributeAnnotation implementation, so they will conflict.
I don't think they are, according to PEP 3107 they are stored in the func_annotations attribute of the function. Note that even if the name *where* the same, attribute annotations only work on classes and instances, while function annotations only apply to functions, not? -- Martijn Pieters
2009/3/10 Martijn Pieters <mj@zopatista.com>:
On Mon, Mar 9, 2009 at 22:20, Dan Korostelev <nadako@gmail.com> wrote:
As you may know, python 3 introduced the concept of annotations for callable objects. That annotations store information about arguments and return values, which is kinda nice language feature that will allow us to do interesting things.
But there's a problem: those annotations will be stored in object's __annotations__ attribute, which is also used by zope.annotation's AttributeAnnotation implementation, so they will conflict.
I don't think they are, according to PEP 3107 they are stored in the func_annotations attribute of the function.
No, they are stored in __annotations__. Look here: http://docs.python.org/3.0/whatsnew/3.0.html#new-syntax Also: nyo@seasaw:~$ python3 Python 3.0.1+ (r301:69556, Feb 24 2009, 13:51:44) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information.
def hello(who:'name') -> None: ... print('Hello, {0}!'.format(who)) ... hello.__annotations__ {'who': 'name', 'return': None}
Note that even if the name *where* the same, attribute annotations only work on classes and instances, while function annotations only apply to functions, not?
Good point. Looks like it is added automatically only for functions/methods. :) However, we can't be sure there won't be annotations for any callable object, because even PEP says that ``we say function, we mean callable object``, so one day we certainly will conflict with something. Also, as Gary pointed out, we mis-use the __*__ name pattern that is now intended for defining special names that have special meaning for python interpreter. And we'll certainly will mis-use the __annotations__ name as it's clearly defined in python 3k. So, after Gary reminded about __*__ names, I think we shoud use something like "_z_annotations". -- WBR, Dan Korostelev
On Mon, Mar 9, 2009 at 23:35, Dan Korostelev <nadako@gmail.com> wrote:
I don't think they are, according to PEP 3107 they are stored in the func_annotations attribute of the function.
No, they are stored in __annotations__. Look here: http://docs.python.org/3.0/whatsnew/3.0.html#new-syntax
Also:
nyo@seasaw:~$ python3 Python 3.0.1+ (r301:69556, Feb 24 2009, 13:51:44) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information.
def hello(who:'name') -> None: ... print('Hello, {0}!'.format(who)) ... hello.__annotations__ {'who': 'name', 'return': None}
Interesting! Perhaps we should file a bug to have the PEP updated with reality then. ;-)
Note that even if the name *where* the same, attribute annotations only work on classes and instances, while function annotations only apply to functions, not?
Good point. Looks like it is added automatically only for functions/methods. :)
However, we can't be sure there won't be annotations for any callable object, because even PEP says that ``we say function, we mean callable object``, so one day we certainly will conflict with something. Also, as Gary pointed out, we mis-use the __*__ name pattern that is now intended for defining special names that have special meaning for python interpreter. And we'll certainly will mis-use the __annotations__ name as it's clearly defined in python 3k.
So, after Gary reminded about __*__ names, I think we shoud use something like "_z_annotations".
Semi-agreed. Tools that access ZODB objects and expect __annotations__ to follow the PEP 3107 conventions will be quite surprised. I doubt that there will be many tools to do so though. Then again, if Python is now explicitly claiming the __*__ naming convention, Zope better avoid it's usage. This means we'll have to fix __parent__ and __name__ usage as well. This will be painful, me thinks.. -- Martijn Pieters
2009/3/10 Martijn Pieters <mj@zopatista.com>:
On Mon, Mar 9, 2009 at 23:35, Dan Korostelev <nadako@gmail.com> wrote:
However, we can't be sure there won't be annotations for any callable object, because even PEP says that ``we say function, we mean callable object``, so one day we certainly will conflict with something. Also, as Gary pointed out, we mis-use the __*__ name pattern that is now intended for defining special names that have special meaning for python interpreter. And we'll certainly will mis-use the __annotations__ name as it's clearly defined in python 3k.
So, after Gary reminded about __*__ names, I think we shoud use something like "_z_annotations".
Semi-agreed. Tools that access ZODB objects and expect __annotations__ to follow the PEP 3107 conventions will be quite surprised. I doubt that there will be many tools to do so though.
Well, with ZODB, that tools don't need to know that objects are from ZODB. To them they are simple Python objects and they expect compatible behaviour.
Then again, if Python is now explicitly claiming the __*__ naming convention, Zope better avoid it's usage. This means we'll have to fix __parent__ and __name__ usage as well. This will be painful, me thinks..
Yep, this will be the pain for sure. However, __parent__ and __name__, and even __bases__ for component registries should be fine for now (however we should think about moving them as well). But with __annotations__ I expect much confusion and problems. -- WBR, Dan Korostelev
On Mon, Mar 9, 2009 at 23:35, Dan Korostelev <nadako@gmail.com> wrote:
def hello(who:'name') -> None: ... print('Hello, {0}!'.format(who)) ... hello.__annotations__ {'who': 'name', 'return': None}
Yup. So, it's stored on the function, not the class. Hence, it will not collide. Might be confusing though. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
2009/3/13 Lennart Regebro <regebro@gmail.com>:
On Mon, Mar 9, 2009 at 23:35, Dan Korostelev <nadako@gmail.com> wrote:
def hello(who:'name') -> None: ... print('Hello, {0}!'.format(who)) ... hello.__annotations__ {'who': 'name', 'return': None}
Yup. So, it's stored on the function, not the class. Hence, it will not collide. Might be confusing though.
As I said before, even if python itself won't add __annotations__ to some callable objects, this thing may be done by third-party tools. The PEP doesn't restrict annotations to functions only, instead there's a note that any callable thing can be annotated like that. -- WBR, Dan Korostelev
On Fri, Mar 13, 2009 at 08:10, Dan Korostelev <nadako@gmail.com> wrote:
As I said before, even if python itself won't add __annotations__ to some callable objects, this thing may be done by third-party tools.
Ah, I have would expected that to go on __call__ but you are right, that probably doens't make any sense, they should be on the object in that case. In any case, __whatever__ is nowadays wrong, and we might want to think about moving to something else. I personally don't like _z_whatever, but _whatever_ is to similar to __whatever__ and __whatever also has implications, and _whatever isn't magic enough, so unless we can think of something better... :) The it's the question if we want to start moving before going over to Python 3 or after. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
Dan Korostelev wrote at 2009-3-10 00:20 +0300:
... But there's a problem: those annotations will be stored in object's __annotations__ attribute, which is also used by zope.annotation's AttributeAnnotation implementation, so they will conflict.
And the problem is far wider: The Python language description reserves all attribute names of the form "__XXXX__" -- and Zope ignores this reservation widespread. Future conflicts are not unlikely. -- Dieter
participants (6)
-
Benji York -
Dan Korostelev -
Dieter Maurer -
Gary Poster -
Lennart Regebro -
Martijn Pieters