Opened 9 years ago

Closed 9 years ago

#503 closed enhancement (wontfix)

Field objects with required arguments shouldn't be keyword arguments.

Reported by: craig@… Owned by: adrian
Component: Core (Other) Version:
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


Please consider making required arguments positional in the Field constructors. As far as I can tell this only applies to CharField which requires maxlength and FloatField which requires max_digits and decimal_places. It feels intuitive to have to enter these before the verbose_name argument in both of these cases, and reads very similar to the actual SQL as well.

name = meta.CharField(32, "Account Name")
balance = meta.FloatField(15, 2, "Current Balance")

Assuming I can attach files to a ticket I'll attach a diff that updates and the core models. I've done some cursory testing (of the tutorial models, both the admin and the user sites), but nothing extensive.

Attachments (1)

required.diff (6.6 KB) - added by craig@… 9 years ago.
makes CharField's maxlength and FloatField's max_digits and decimal_places positional non-defaulted arguments for the constructors

Download all attachments as: .zip

Change History (4)

Changed 9 years ago by craig@…

makes CharField's maxlength and FloatField's max_digits and decimal_places positional non-defaulted arguments for the constructors

comment:1 Changed 9 years ago by jacob

The The Zen of Python, second koan:

Explicit is better than implicit.

To me, meta.FloatField(15, 2, "Current Balance") is extremely unclear -- I'll constantly need to be looking up the order to give the numbers in. This might be worth thinking about for CharField so I'll leave the ticket open.

comment:2 Changed 9 years ago by craig@…

Somebody suggested this for CharField on #django yesterday, and I liked the idea of less typing. Then I later thought that what's good for CharField would be good of FloatField too.

However, now that I'm thinking about it, this is only clear if you're accustomed to NUMERIC and DECIMAL data types in SQL. I just spend so much time using SQL that I sometimes forget how un-intuitive of a language it is.

There's no reason model syntax should mirror SQL syntax at the peril of clarity though, and I'm not sure that meta.CharField(32, "Account Name") is any more clear than the FloatField example, so maybe this ticket should be closed. I'll leave that to someone else to decide.

comment:3 Changed 9 years ago by adrian

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

Closing for the reasons outlined by Craig in the last comment.

Add Comment

Modify Ticket

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

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

Note: See TracTickets for help on using tickets.