Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

__init__() got an unexpected keyword argument 'mimetype' #77

Open
antonagestam opened this issue Apr 23, 2014 · 17 comments · May be fixed by #78
Open

__init__() got an unexpected keyword argument 'mimetype' #77

antonagestam opened this issue Apr 23, 2014 · 17 comments · May be fixed by #78

Comments

@antonagestam
Copy link

Passing mimetype to HttpResponse is deprecated and removed in Django 1.7 as per django/django@8eadbc5

(https://github.com/caffeinehit/django-oauth2-provider/blob/master/provider/views.py#L491)

@antonagestam antonagestam linked a pull request Apr 23, 2014 that will close this issue
@psychok7
Copy link

psychok7 commented Sep 9, 2014

any news on this?? i am having the same problem with Django 1.7

@edmenendez
Copy link

Same with Django 1.7. It's happening everywhere else I'm trying to return a HttpResponse with a mimetype. So this is not specific to django-oauth2-provider.

@edmenendez
Copy link

And.. It's because it's now called content_type.. not mimetype and HttpResponse should be called like

    return HttpResponse(
                json.dumps(response_data), content_type='application/json'
     )

@fankewong
Copy link

I've the same issue here in 1.7 ... anyone have solution?

mimetype="application/json"
File "/usr/local/lib/python2.7/dist-packages/django/http/response.py", line 318, in init
super(HttpResponse, self).init(*args, **kwargs)
TypeError: init() got an unexpected keyword argument 'mimetype'

@psychok7
Copy link

my solution was to start using django oauth toolkit , when this gets fixed i might give it another try

@edmenendez
Copy link

Yes, change line 491 at https://github.com/caffeinehit/django-oauth2-provider/blob/master/provider/views.py#L491 to use content_type instead of mimetype.

@antonagestam
Copy link
Author

@edmenendez In 1.7 there's a JSONResponse class, I think I used that in the pull request that's linked to this issue.

@beaugunderson
Copy link

#93 fixes this as well.

@theladyjaye
Copy link

+1 on this

@tomwalters
Copy link

Further to the comment by @edmenendez there are a number of lines in views.py namely: 301, 466 and 491 - the new (v1.7) HttpResponse constructor uses the param name content_type in place of mimetype, so a simple solution is to make the replacement.

@bangonkali
Copy link

Hi Guys, I followed the recommendations in this thread as a temporary solution for this issue. However, I'm using PIP. Somehow my latest PIP Install didn't include the fix. How do I make sure future PIP installations include the fix for this app? At the moment I'm manually fixing stuff on the server side and on my dev machine after using PIP. I really like PIP so I hope the fix will be available with PIP installation soons. Thanks.

@ghost
Copy link

ghost commented Jan 1, 2015

Further to the comment by @edmenendez and @tomwalters above, changing all instances of the mimetype function parameter and return in views.py as described worked for me. Django 1.7.1

@kevbradwick
Copy link

Any ideas when this fix will make it in to master and released?

@blag
Copy link

blag commented Jan 14, 2015

@kevbradwick Upstream appears to be dead, so maybe never. If you absolutely cannot switch over to using Django OAuth Toolkit, then you should be able to use @glassresistor's zip file or repo.

Use pip to install the zip file:

$ pip install https://github.com/glassresistor/django-oauth2-provider/archive/stable.zip#django-oauth2-provider

or specify it directly in requirements.txt:

...
https://github.com/glassresistor/django-oauth2-provider/archive/stable.zip#django-oauth2-provider
...

Tell pip to install from @glassresistor's repository:

$ pip install -e git+https://github.com/glassresistor/django-oauth2-provider.git#egg=django-oauth2-provider

or specify it directly in requirements.txt:

...
-e git+https://github.com/glassresistor/django-oauth2-provider.git#egg=django-oauth2-provider
...

And just a heads up: unfortunately pip does not save where it installed packages from, so running pip freeze > requirements.txt will not write the appropriate URL to the requirements.txt file. C'est la vie, I guess.

@aravindaran
Copy link

In Django 1.6, the HttpResponse is like
if mimetype:
warnings.warn("Using mimetype keyword argument is deprecated, use"
" content_type instead",
DeprecationWarning, stacklevel=2)
content_type = mimetype

We are just warning and assigning the mimetype to the content_type.

In Django 1.8, we are not using mimetype. Instead of this directly we are assigning the value like "image/png", etc.., to the content_type. Just a DRY concept.

@alvinyeats
Copy link

I've the same issue here in 1.6.11

mimetype="application/json"
File "/usr/local/lib/python2.7/dist-packages/django/http/response.py", line 318, in init
super(HttpResponse, self).init(_args, *_kwargs)
TypeError: init() got an unexpected keyword argument 'mimetype'

Further to the comment by @edmenendez and @tomwalters above, changing all instances of the mimetype function parameter and return in views.py as described worked for me. Django 1.6.11

at https://docs.djangoproject.com/en/1.9/internals/deprecation/#deprecation-removed-in-1-7
I find this:
The mimetype argument to the init methods of HttpResponse, SimpleTemplateResponse, and TemplateResponse, will be removed. content_type should be used instead. This also applies to the render_to_response() shortcut and the sitemap views, index() and sitemap().

but i can't understand why the warning appear in django 1.6 until i saw the comment by @aravindaran

@ckarrie
Copy link

ckarrie commented Oct 26, 2016

Fixed this in https://bitbucket.org/ckarrie/django-piston

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.