Code

Opened 14 months ago

Last modified 6 months ago

#19973 assigned Cleanup/optimization

Management commands migration to argparse

Reported by: jose Owned by: jose
Component: Core (Management commands) Version: master
Severity: Normal Keywords: optparse, argparse, basecommand
Cc: hans@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The class BaseCommand, from which developers subclass their own management commands, is using the `optparse` module, which is actually deprecated.

If there are no important reasons to remain using the deprecated module, perhaps would be a good idea to port the BaseCommand code to the new module `argparse`, which will be used in Python 3.

Attachments (0)

Change History (7)

comment:1 Changed 14 months ago by ramiro

  • Easy pickings unset
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

Good idea, has been discussed before (but there isn't anassociated ticket so thanks for opening this one).

But possible only once the minimal Python version supported by Django gets to the 2.7 level, such is the version where argparse got added to the stdlib.

comment:2 Changed 14 months ago by jose

Ok. I think that since I've took part some days ago in fixing the ticket #19877 and I've got familiar with that part, I can also try to fix this one. So it can be appended to Django master code when it reaches the 2.7 Python as minimal version supported.

comment:3 Changed 14 months ago by jose

  • Owner changed from nobody to jose
  • Status changed from new to assigned

comment:4 Changed 14 months ago by carljm

We'll need to provide a deprecation path and migration strategy for authors of custom management commands, since optparse is exposed directly to them via the definition of additional options for a custom command.

comment:5 Changed 11 months ago by jokerejoker

  • Cc hans@… added

comment:6 Changed 8 months ago by mjtamlyn

We are now able to do this as Django master is 2.7 only. I'm not having many great ideas about how to support both at once, my instinct says we'll need to do something like providing a flag on the Command instance to say "use_argpase" instead. Even this isn't clear in terms of how it would work.

Then again, there is no planned removal date for optparse (http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse) so it's not really urgent.

comment:7 Changed 6 months ago by claudep

Before starting with the implementation, there is a design decision to make. argparse doesn't provide the same declarative syntax that optparse used to provide with make_option. I see two main ways to go forward:

  1. Keep declarative syntax and mostly the same Command API that we have now. Instead of importing make_option from optparse, we would import it from a Django-provided utility, optionally renaming it make_argument. Internally, this would only build a list of parameters that we would then pass to add_argument calls in create_parser.
    Advantages: nicer declarative syntax, less changes for custom command writers (and accessorily easier for call_command to get default values without instantiating the parser)
  1. Depart from the current declarative syntax and change the documentation about adding options for custom commands, basically instructing to subclass create_parser (or more probably create a new subclassable method BaseCommand.add_arguments(self, parser)) and to add arguments by calling parser.add_argument(<params>).
    Advantages: closer approach to standard Python

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as assigned
The owner will be changed from jose to anonymous. Next status will be 'assigned'
The ticket will be disowned. Next status will be 'new'
as The resolution will be set. Next status will be 'closed'
Author


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

 
Note: See TracTickets for help on using tickets.