Code

Opened 5 years ago

Closed 5 years ago

#10806 closed (wontfix)

raise TypeError on form instantiation if data/files parameter isn't a dict.

Reported by: ajs Owned by: nobody
Component: Forms Version: master
Severity: Keywords: KeyError forms dict instantiation
Cc: ajs Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

No error is thrown if a form is passed a non dict value to it's data or files parameter on instantiation.
When the form is validated a AttributeError: 'type' object has no attribute 'get' is raised.
I found it confusing that the form instantiation was ok and but somewhere in my template everything broke.

The attached patch checks that the data/files are instances of dict or django.utils.datastructures.MergeDict
if not it raises a TypeError.

Tests are included.

There are 2 issues that need to be looked at:

  1. passing an instance of something that behaves like a dict but isn't a subclass of dict or MergeDict, won't work with this patch applied, which I'm not really happy about but my python-fu isn't strong enough to come up with a better solution. Rewriting the patch to use getattr is a possibility.
  2. It might be considered an backwards incompatible change since now TypeError can be raised.

Attachments (1)

forms-typeerror.patch (2.0 KB) - added by ajs 5 years ago.

Download all attachments as: .zip

Change History (5)

Changed 5 years ago by ajs

comment:1 Changed 5 years ago by Alex

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

I'm marking this as DDN, however my opinion is this should be wontfixed. This is a violation of a fairly basic python principle that if it walks like a duck and talks like a duck, we'll treat it like a duck. Further, as you've said it already raises an expcetion when whatever you pass ceases to be sufficiently "duck-like", so I don't see this as assisting anything.

comment:2 follow-up: Changed 5 years ago by ajs

I think it assists in that the exception gives you the "correct" reason. In the current situation you get an Exception telling you that object doesn't have an attribute get. Which IMHO isn't really helpful.

On the other hand it's going to be difficult recognizing everything that looks like a duck.

comment:3 in reply to: ↑ 2 Changed 5 years ago by Alex

Replying to ajs:

On the other hand it's going to be difficult recognizing everything that looks like a duck.

That's why we don't actually check under the feathers to make sure it's a duck, so long as it quacks ok.

comment:4 Changed 5 years ago by mtredinnick

  • Resolution set to wontfix
  • Status changed from new to closed

This is indeed a wontfix. Forms should be passed things that can obey the right protocol, essentially. Which is what is being reported by that exception (it doesn't have a method to retrieve the information). Doing strong type restriction goes against the flow and inhibits usage a bit only for the benefit of cases of programmer error, which are by far the minority situation (sure, it doesn't seem like that when you're developing, but restricting normal use-cases because it makes it 30 seconds easier to spot a typo isn't long-term helpful0.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.