AttributeError: 'MetaTypedInterface' object has no attribute '__name__'

Bug #811792 reported by Zooko Wilcox-O'Hearn
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Tahoe-LAFS
Fix Released
Unknown
nevow
Fix Committed
Undecided
Unassigned
zope.interface
Fix Released
Medium
Tres Seaver

Bug Description

This is with Nevow 0.10.0 and zope.interface 3.6.4. David-Sarah Hopwood and Drew Perttula each independently reported this error. (I haven't seen it personally, I'm just reporting what they posted.) Drew included a patch to zope.interface work-around it:

http://drewp.quickwitretort.com/2011/07/08/0

http://codepad.org/wd1UUnhh

Related branches

Tres Seaver (tseaver)
Changed in zope.interface:
assignee: nobody → Tres Seaver (tseaver)
importance: Undecided → Medium
status: New → Confirmed
Changed in tahoe-lafs:
status: Unknown → New
Changed in tahoe-lafs:
status: New → Confirmed
Changed in tahoe-lafs:
status: Confirmed → Fix Released
Changed in nevow:
status: New → Confirmed
Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

The tahoe-lafs mailing list got a letter from a user who couldn't run tahoe-lafs because of this issue:

http://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006608.html

Revision history for this message
Tres Seaver (tseaver) wrote :

After looking at this, I find that the bug is in formless' MetaTypedInterface, which is trying to hash the partially constructed object from within its own __new__ (i.e., before invoking the __init__ of its superclass).

Note that the proposed change to zope.interface (using '' as the default value for __name__) actually defeats the point of storing the values in the module-scope '_typedInterfaceMetadata' mapping: the object will hash differently after it is fully initialized, and therefore won't be found in that mapping at all. A better fix would be to set __name__ on the instance inside the __new__.

Changed in zope.interface:
status: Confirmed → Invalid
Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Hi Tres Seaver: thanks for looking into this.

The Tahoe-LAFS project has a new stable release scheduled to come out soon, and this issue is causing problems for our users. Even though this isn't "zope.interface's fault" exactly, it is a problem that our users have if they have zope.interface 3.6.4 and they don't have the problem if they have an older version of zope.interface. At the moment Tahoe-LAFS has a work-around in our dependency specification by saying "Tahoe-LAFS requires zope.interface 3.3.1, 3.5.3, or 3.6.1":

http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/_auto_deps.py?annotate=blame&rev=5082

This has already proven problematic for a user (actually a developer) who had zope.interface 3.5.1 and was on a train when they discovered that our build system rejected it. Also it is really unsatisfying because as soon as a new version of Nevow comes out (let's assume it will be numbered 0.11.0), then we would like for users to be able to run with any version of zope.interface as long as they have Nevow >= 0.11.0. (Or, it would be okay if they ran with any version of Nevow as long as they had zope.interface < 3.6.4, but there's no way to express that alternative constraint in the Python dependency language).

Anyway, I was wondering if you had any ideas about how to work-around this problem in zope.interface. If you released a new zope.interface (let's assume it will be numbered 3.6.5) then a user would be able to get past this problem by upgrading zope.interface. This would be another way for them to get unstuck, in addition to the currently available way (downgrade zope.interface) and the hopefully imminent way (upgrade Nevow to >= 0.11.0).

Thanks!

Changed in tahoe-lafs:
status: Fix Released → New
Revision history for this message
Tres Seaver (tseaver) wrote :

By my analysis, releasing a version of zope.interface with the fallback proposed in the patch is not a reasonable thing to do:

- For "normal" uses of zope.interface, the proposed fallback behavior won't ever be triggered

- For the nevow case: making __hash__ "work" (i.e., not raise AttributeError) before assigning the instance's '__name__' will still lead to a later failure, because the value stored in the dict will not be findable: objects used as keys in a dict *must* have a '__hash__' which always returns the same value for a given instance.

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Okay, thanks.

Does this imply that users of zope.interface 3.6.1 and Nevow would have encountered that later failure? This is entirely plausible because, as far as I know, there are no actual users of that part of Nevow ("formless"), so if with earlier versions of zope.interface it would have failed at use time and with zope.interface 3.6.4 it started failing at import time, nobody would have noticed the former failure.

Revision history for this message
Tres Seaver (tseaver) wrote :

Prior to zope.interface 3.6.4, interface objects used the '__hash__' of the base 'object' type, which used the object's address as its hash: under Python3, objects which override '__eq__' are also required to override '__hash__'.

I would say that you need either to pin zope.interface to version 3.6.1, or else require a version of nevow which doesn't attempt to hash the interface object inside its '__new__' (if using the object as a dictionary key inside its own __new__ is truly necessary, then nevow should arrange to assign the '__name__' beforehand).

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Tres Seaver:

Thanks. The fix for Nevow (https://bugs.launchpad.net/nevow/+bug/811792 ) removes the entire part of Nevow (formless) which has this code. There's no bugfix as certain to work as removing the code in question!

Regards,

Zooko

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Another user has written to the Tahoe-LAFS mailing list saying that they can't build Tahoe-LAFS:

http://tahoe-lafs.org/pipermail/tahoe-dev/2011-August/006651.html

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Another user joined our IRC channel to say they couldn't build Tahoe-LAFS. It was this same problem. Here is the stack trace they provided: http://codepad.org/gE2jkft0

Revision history for this message
Glyph Lefkowitz (glyph) wrote :

Zooko, thanks for reporting this and following up, but the right thing for these users to do is to use the 'this bug affects me too' widget up above to indicate its importance to them. It doesn't help to have lots of comments with the same traceback in them.

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Oh, right, thanks. Most of my users probably don't have launchpad accounts, but I'll encourage them to sign up and do that. Sorry for the noise.

Revision history for this message
Tres Seaver (tseaver) wrote :

I have checked in a change to zope.interface for the 3.6.5 release
which tweaks the behavior of '__hash__' as follows:

If '__module__' or '__name__' are not yet set on the instance,
'__hash__' now issues a warning and returns a fixed constant.

Changed in zope.interface:
status: Invalid → Fix Committed
status: Fix Committed → Fix Released
Revision history for this message
Tres Seaver (tseaver) wrote :
Revision history for this message
Arfrever Frehtes Taifersar Arahesis (arfrever-fta) wrote :

The 'with' statement introduced in src/zope/interface/tests/test_interface.py requires Python >=2.6. It would work in Python 2.5 after addition of 'from __future__ import with_statement'.

Revision history for this message
Tres Seaver (tseaver) wrote :

Thanks -- I've fixed the syntax error under Pytnon 2.5, bailing out on the
test which uses the not-yet-present 'warnings.catch_warnings':

  http://svn.zope.org/zope.interface/?rev=122559&view=rev

Revision history for this message
Gediminas Paulauskas (menesis) wrote :

With the last fix it will still fail under Python 2.4 on from __future__ import with_statement.

Given the problems that the ordering fix caused, requiring further 2+ releases, I suggest re-releasing 3.6.2 as 3.6.6, create 3.6 branch for ztk 1.0/1.1, and release trunk as 3.7.0 . It is incompatible, after all.

Revision history for this message
Tres Seaver (tseaver) wrote : Re: [Bug 811792] Re: AttributeError: 'MetaTypedInterface' object has no attribute '__name__'

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/12/2011 12:39 PM, Gediminas Paulauskas wrote:
> With the last fix it will still fail under Python 2.4 on from
> __future__ import with_statement.
>
> Given the problems that the ordering fix caused, requiring further
> 2+ releases, I suggest re-releasing 3.6.2 as 3.6.6, create 3.6 branch
> for ztk 1.0/1.1, and release trunk as 3.7.0 . It is incompatible,
> after all.

This discussion needs to move to the zope-dev list.

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5FZ/AACgkQ+gerLs4ltQ4ibACffvg9J97b/P0SGRnPxxhRGT+d
3nEAoM92WASn+ypmHBq8/Rxvoti3/6t/
=PnCn
-----END PGP SIGNATURE-----

Changed in tahoe-lafs:
status: New → Fix Released
Changed in nevow:
status: Confirmed → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.