TypeError: 'function' object is not iterable

[Ryan J Ollos]

How to Reproduce

While doing a GET operation on /newhack, Trac issued an internal error.

(please provide additional details here)

Request parameters:

{}

User agent: #USER_AGENT#

System Information

Trac	1.0.1
Trac	1.0.1
Babel	0.9.6
Docutils	0.7
FullBlog	0.1.1-r13462
Genshi	0.6 (with speedups)
mod_wsgi	3.3 (WSGIProcessGroup trac-hacks-010 WSGIApplicationGroup %{GLOBAL})
psycopg2	2.2.1
Pygments	1.6
Python	2.6.6 (r266:84292, Dec 27 2010, 00:18:12) [GCC 4.4.5]
Python	2.6.6 (r266:84292, Dec 27 2010, 00:18:12) [GCC 4.4.5]
pytz	2013b
pytz	2013b
RPC	1.1.2-r13203
setuptools	0.6
setuptools	0.6
Subversion	1.6.12 (r955767)
jQuery	#JQUERY#

Enabled Plugins

BlogDraftPlugin	N/A
ChangeLogMacro	0.2-r12377
EmailProcessor	r10962
FootNoteMacro	1.03-r13269
SvnAuthzAdminPlugin	0.2
TracAccountManager	0.4.3
TracAcronyms	0.2dev-r10459
TracAutoWikify	0.2dev-r11905
TracFullBlogPlugin	0.1.1-r13462
TracHacks	3.0dev-r13544
TracIncludeMacro	3.0.0dev-r12030
TracIniAdminPanel	1.0.1-r13010
TracNewsFlash	1.0.1
TracPoll	0.3.0dev-r11670
TracServerSideRedirectPlugin	0.4
TracSpamFilter	0.8.0dev-r11796
TracTags	0.7dev-r13797
TracTocMacro	11.0.0.3
TracXMLRPC	1.1.2-r13203

Python Traceback

Traceback (most recent call last):
  File "/srv/trac-hacks.org/pve/lib/python2.6/site-packages/Trac-1.0.1-py2.6.egg/trac/web/main.py", line 497, in _dispatch_request
    dispatcher.dispatch(req)
  File "/srv/trac-hacks.org/pve/lib/python2.6/site-packages/Trac-1.0.1-py2.6.egg/trac/web/main.py", line 214, in dispatch
    resp = chosen_handler.process_request(req)
  File "/srv/trac-hacks.org/pve/lib/python2.6/site-packages/TracHacks-3.0dev_r13544-py2.6.egg/trachacks/web_ui.py", line 249, in process_request
    return self.render_new(req, data, hacks)
  File "/srv/trac-hacks.org/pve/lib/python2.6/site-packages/TracHacks-3.0dev_r13544-py2.6.egg/trachacks/web_ui.py", line 365, in render_new
    render_cloud(req, cloud, cloud_renderer)
  File "/srv/trac-hacks.org/pve/lib/python2.6/site-packages/TracTags-0.7dev_r13797-py2.6.egg/tractags/macros.py", line 367, in render_cloud
    li = builder.li(renderer(tag, count, percent))
  File "/srv/trac-hacks.org/pve/lib/python2.6/site-packages/TracTags-0.7dev_r13797-py2.6.egg/tractags/macros.py", line 336, in default_renderer
    href = self.get_href(req, realms, tag=Resource('tag', tag))
  File "/srv/trac-hacks.org/pve/lib/python2.6/site-packages/TracTags-0.7dev_r13797-py2.6.egg/tractags/macros.py", line 306, in get_href
    form_realms = dict((realm, 'on') for realm in realms)
TypeError: 'function' object is not iterable

[Ryan J Ollos]

This is probably caused by upgrading TagsPlugin today (and why I need to do more testing before wildly upgrading plugins).

I can probably look into it tomorrow, but I suspect hasienda or jun66j5 will spot the issue right off.

[Steffen Hoffmann]

Obviously the render_cloud() call in TracHacksPlugin is not updated yet. 'realms' argument has pushed 'renderer', the first optional kwarg, out of its former, third position - a late and silent API change, likely without looking at other plugins for compatibility issues, sorry.

[Jun Omae]

In 13801:

Fixed not showing local variables in stack frames when New Hack page raises an internal error (refs #11659)

[Jun Omae]

Oh, I'm wrong. I've broke the compatibilities of TagWikiMacros.render_cloud. I've thought that only symbols in tractags.api is public.

I think we could move realms argument to the last to keep the compatibilities.

tractags/macros.py

@@ -186 +186 @@
                 # Allow faster per tag query, side steps permission checks.
                 all_tags = tag_system.get_all_tags(req, realms=realms)
             mincount = 'mincount' in kw and kw['mincount'] or None
-            return self.render_cloud(req, all_tags, realms,
+            return self.render_cloud(req, all_tags,
                                      caseless_sort=self.caseless_sort,
-                                     mincount=mincount)
+                                     mincount=mincount, realms=realms)
         elif name == 'ListTagged':
             if content and _OBSOLETE_ARGS_RE.search(content):
                 data = {'warning': 'obsolete_args'}
@@ -316 +316 @@
                         realms=realms, listtagged_per_page=per_page,
                         listtagged_page=page, **kwargs)
 
-    def render_cloud(self, req, cloud, realms, renderer=None,
-                     caseless_sort=False, mincount=None):
+    def render_cloud(self, req, cloud, renderer=None, caseless_sort=False,
+                     mincount=None, realms=()):
         """Render a tag cloud.
 
         :cloud: Dictionary of {object: count} representing the cloud.

[Jun Omae]

I've arrived this ticket from timeline rss on trac-hacks ;)

[Steffen Hoffmann]

Replying to jun66j5:

Oh, I'm wrong. I've broke the compatibilities of TagWikiMacros.render_cloud. I've thought that only symbols in tractags.api is public.

I was a bit uneasy about adding realms to the method as done in [13754], but didn't expect the high integration of TagsPlugin into TracHacksPlugin either.

For what its worth this looks like a singularity. The only other plugin I found is TracZoteroPlugin, but this uses its own version of render_cloud(), formerly copied from here.

I think we could move realms argument to the last to keep the compatibilities.

Yes, we can improve [13754] for compatibility. Normally I'd like to keep it as it is for signature clarity of render_cloud(). Realms at the end doesn't look as lean as now, but that's all about it. Changes are minimal, and breaking other code just for the thread-safe fix here is unprofessional.

[Steffen Hoffmann]

In 13803:

TagsPlugin: Restore signature of TagWikiMacros.render_cloud() for compatibility, refs #11659.

As we found this plugin rather deeply integrated into TracHacksPlugin, this
is the way to go.

[Steffen Hoffmann]

Due to the pain I feel about the broken /newhack link I'll replace the TagsPlugin install here at t-h.o with this revision soon, but feel free to do it before me.

[Ryan J Ollos]

Thanks for the quick fix. I updated t-h.o and /newhack seems to be okay now.

[Ryan J Ollos]

I'll leave this ticket assigned to TracHacksPlugin since I'm not sure whether you want it associated with TagsPlugin.

[Steffen Hoffmann]

Replying to rjollos:

I'll leave this ticket assigned to TracHacksPlugin since I'm not sure whether you want it associated with TagsPlugin.

Oh, sure, this is on the TagsPlugin side, but I didn't even notice it was not assigned to it. Will be mentioned in the tractags-0.7 release as well.

[Steffen Hoffmann]

In 13815:

TagsPlugin: Completing preparation for v0.7 release.

Availability of that code as stable, tagged release
closes #2429, #3359, #3610, #3624, #3677, #3754, #3864, #3947, #3983, #4078, #4277, #4503, #4799, #5523, #7787, #7857, #8638, #9057, #9058, #9059, #9060, #9061, #9062, #9063, #9149, #9210, #9521, #9630, #9636, #10032, #10416, #10636, #11096, #11147, #11152, #11274, #11302, #11658 and #11659.

Additionally there are some issues and enhancement requests showing progress,
but known to require more work to resolve them satisfactorily, specifically
refs #2804, #4200, #8747 and #9064.

Thanks to all contributors and followers, that enabled and encouraged a good
portion of this development work.