[Zope-dev] Python3 and attribute annotations.

[Gary Poster]

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.html 
.  It may come off more strongly than it should, but I still find the  
point to be a good one.)

Gary