Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

match_param cannot be supplied with a dict in 1.2 and 1.3 branches as documented #425

Closed
simonyarde opened this issue Feb 6, 2012 · 1 comment
Labels

Comments

@simonyarde
Copy link

Supplying a dict to the match_param of add_view results in the following error::

 File "/Users/simonyarde/development/pyramid/pyramid/pyramid/config/__init__.py", line 1093, in resolveConflicts
   L = unique.setdefault(discriminator, [])

TypeError: unhashable type: 'dict'

The discriminator tuple may not contain the match_param dict because dicts are mutable and therefore unhashable::

discriminator
('view', None, '', None, , None, None, None, 'test', None, False, None, None, None, {'test': '1'})

Pyramid passes it's own tests for match_param because resolveConflicts is not invoked:

test_match_param_from_dict (pyramid.tests.test_config.test_util.Test__make_predicates) ... ok
test_match_param_from_dict_fails (pyramid.tests.test_config.test_util.Test__make_predicates) ... ok
test_match_param_from_string (pyramid.tests.test_config.test_util.Test__make_predicates) ... ok
test_match_param_from_string_fails (pyramid.tests.test_config.test_util.Test__make_predicates) ... ok.

I quickly hacked mine by storing the string repr of match_param in the discriminator, which is ugly but works.

Perhaps it would be better to configure match_param with a tuple::

('foo=bar', 'b=2', 'c=3')

since python doesn't have an immutable dict object suitable for configuration purposes.

There would (probably) be no objection to changing configuration since this feature hasn't worked in 1.2 or 1.3 so there aren't any projects using it?

@mmerickel
Copy link
Member

I think your proposal of using a tuple here is a good one. It'd be more consistent with the current behavior of request_method=('GET', 'POST').

mmerickel added a commit that referenced this issue Feb 7, 2012
mmerickel added a commit that referenced this issue Feb 7, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants