Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#24518 closed Bug (worksforme)

OptionParser verbosity not cast to int (Python3)

Reported by: Thierry Jossermoz Owned by: Thierry Jossermoz
Component: Core (Management commands) Version: 1.8
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description (last modified by Thierry Jossermoz)

With Python3, when not using argparse for a management command, the verbosity option uses a type=choice, which leads to a TypeError: unorderable types: str() > int() in django/core/management/commands/ at line 65 (if options['verbosity'] > 0)

The problem comes from this line in django/core/management/

parser.add_option('-v', '--verbosity', action='store', dest='verbosity', default='1',
    type='choice', choices=['0', '1', '2', '3'],
    help='Verbosity level; 0=minimal output, 1=normal output, 2=verbose output, 3=very verbose output')

Change History (14)

comment:1 by Thierry Jossermoz, 9 years ago

Description: modified (diff)
Status: newassigned

comment:2 by Claude Paroz, 9 years ago

Resolution: wontfix
Status: assignedclosed

I'm not sure we want to change that. If you look at Django management commands in pre-1.8 versions, you'll read many self.verbosity = int(options.get('verbosity')) or if int(options['verbosity']) > 0: patterns. The future is definitely using argparse, so if for any reason you still want to keep using optparse, you should continue to cast the result of the verbosity option to int.
Your proposed patch would remove the option list checking of verbosity, which would be slightly backwards incompatible.

comment:3 by Brandon Konkle, 9 years ago

Resolution: wontfix
Status: closednew
Version: 1.8rc11.8

I'm running into this when trying to run core Django management commands in 1.8 on Python 3.4. 'makemigrations' and 'test' are two examples. I simply cannot run these management commands in Python 3.4.

Here's a screenshot:

comment:4 by Brandon Konkle, 9 years ago

Resolution: fixed
Status: newclosed

I found the problem:

Verbosity used to be set like this:

self.verbosity = int(options.get('verbosity'))

Now it's set like this:

self.verbosity = options.get('verbosity')

There's no int conversion in 1.8 like there was in 1.7, a change made during the conversion to argparse. I assume the fix would be to go back to converting to int. I'll work up a pull request on Github.

comment:5 by Brandon Konkle, 9 years ago

Resolution: fixed
Status: closednew

comment:6 by Brandon Konkle, 9 years ago

Has patch: set

comment:7 by Tim Graham, 9 years ago works for me using the tutorial and Python 3.4.3. Are you sure this isn't caused by a third-party library somehow? Maybe it's worth fixing for backwards compatibility purposes, but I'd like to understand the reason for it.

comment:8 by Claude Paroz, 9 years ago

Resolution: needsinfo
Status: newclosed

I can only reproduce the issue when calling call_command and passing a string to verbosity which I would classify as a user programming error, not a bug in Django. When using the command line directly, argparse is converting to integer for us.

comment:9 by Brandon Konkle, 9 years ago

You are absolutely right. I discovered the real origin of the issue - an older version of django-configurations was adding an option to the BaseCommand.option_list, which was causing it to use optparse for all management commands rather than argparse. None of the add_arguments() methods were being called at all. I updated django-configurations, and the problem is now solved. Sorry for the trouble!

comment:10 by Claude Paroz, 9 years ago

Resolution: needsinfoworksforme

comment:11 by Daniel Hahler, 9 years ago

For reference: I am suggesting to use int for verbosity also with the old parser for consistency: see #24769 (which has a patch/PR).

comment:12 by Claude Paroz, 9 years ago

I would have supported this request if this had popped up before 1.8 final. Now I'm reluctant to change this in a stable release. And then, if we don't do it for 1.8, it makes not much sense to do it for 1.9 either. But I'll let someone else take the final decision.

in reply to:  12 comment:13 by Thierry Jossermoz, 9 years ago

This ticket was created for 1.8 rc1

comment:14 by Claude Paroz, 9 years ago

Sorry, my bad. I admit that the scenario of third-party apps monkey-patching core commands was not a use case I considered when writing the compatibility layer.

Note: See TracTickets for help on using tickets.
Back to Top