Unfortunately in the real live the choices allowed for the connection are frequently limited by some application logic e.g. you may add answers only to questions created by you. In some simple(rare) cases this can be easy achieved using choices or limit_choices_to attributes in the models.ForeignKey call.
In the case of choices you just have to pass list/tuple each element of which contains the value to be stored and human readable name for the choice. Unfortunately this one is computed on server run and is not updated with new items during run-time.
If you use limit_choices_to you may pass to it some kind of filter expression e.g. limit_choices_to = {'pub_date__lte': datetime.now} but this not always can do the job.
Speciality: So if you want dynamic choices in the admin drop down you have to write a method that will return list with options and bind it to the form(as shown in Django forms ChoiceField with dynamic values…) which is used by admin.
This will work great but if you decided to add this column in admin`s list_filter you will see all element from the connected model in filter. How to limit them to the same list used for the form choices?
Solution: The simplest solutions is to extend RelatedFilterSpec, overwrite its default choices and add a single row to the model:

fromdjango.contrib.admin.filterspecsimportFilterSpec,RelatedFilterSpecclassCustomFilterSpec(RelatedFilterSpec):def__init__(self,*args,**kwargs):super(CustomFilterSpec,self).__init__(*args,**kwargs)self.lookup_choices=get_questions()#this method returns the dynamic listFilterSpec.filter_specs.insert(0,(lambdaf:bool(f.relandhasattr(f,'custom_filter_spec')),CustomFilterSpec))classAnswer(models.Model):# some fields herequestion=models.ForeignKey(Question)question.custom_filter_spec=True# this is used to identify the fields which use the custom filter

Final word: The solutions is pretty simple and really easy to implement but should be used carefully. If your filtering method(in my case get_questions) is slow/resource consuming it may bring you troubles. Here is the place where and you should think about caching it. This is a place where a application cache can be used. Hope this will help you as much as it helped me.

... or how to get a dynamic drop-down list with Django forms

The problem: Lets say that you need a form with a drop-down list that have dynamic values. With Django this can be done simple and fast, but if you are new you may get yourself into a trap. In a standard form(with static values in the drop-down) your code will be something like this:

So if you want the values to be dynamic(or dependent of some logic) you can simply modify your code to something like this:

defget_my_choices():# you place some logic herereturnchoices_listclassMyForm(forms.Form):my_choice_field=forms.ChoiceField(choices=get_my_choices())

and here you will fail(not absolutely). This is a common mistake and sooner or later you will see what you messed but it my be too late.
Speciality: the trick is that in this case my_choice_field choices are initialized on server (re)start. Or in other words once you run the server the choices are loaded(calculated) and they will not change until next (re)start. This mean that your logic will be executed only once. This will be OK if your logic is server specific(depends from server settings) or "semi-dynamic" in any other way. But you need this list to be updated on every form load you will need to use something the form __init__ method.
Solution: fortunately the form`s class has an __init__ method that is called on every form load. Most of the times you skipped it in the form definition but now you will have to use it.

defget_my_choices():# you place some logic herereturnchoices_listclassMyForm(forms.Form):def__init__(self,*args,**kwargs):super(MyForm,self).__init__(*args,**kwargs)self.fields['my_choice_field']=forms.ChoiceField(choices=get_my_choices())

You first call the __init__ method of the parent class(Form) using the super keyword and then declare your dynamic fields(in this case my_choice_field). With this code get_my_choices is called on every form load and you will get your dynamic drop-down.

Final words: have in mind that this method also have one strong drawback. If your application have a heavy load, executing a logic on every form load may(will) bring you troubles. So some caching of the form or the logic result may be useful.
And remember If you have other approach, idea or question I am always ready to hear it.