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

Added error handling at import django.utils.six module. #758 #759

Merged
merged 1 commit into from Sep 10, 2019
Merged

Added error handling at import django.utils.six module. #758 #759

merged 1 commit into from Sep 10, 2019

Conversation

yukihira1992
Copy link
Contributor

@yukihira1992 yukihira1992 commented Sep 10, 2019

I fixed #758.
If django-storages ends support for Python2, close this.

@jschneier
Copy link
Owner

Thanks for this, I'm not quite sure why they removed six before 1.11 is no longer supported. I think a better way to solve this is to do try except rather than depending on six.

Want to take a crack at that?

@yukihira1992 yukihira1992 changed the title Changed django.utils.six to six. #758 Added error handling at import django.utils.six module. #758 Sep 10, 2019
@yukihira1992
Copy link
Contributor Author

Removed six and added error handling.

@jschneier jschneier merged commit 0ab2b1e into jschneier:master Sep 10, 2019
@yukihira1992 yukihira1992 deleted the support_django3 branch September 10, 2019 17:32
@jdufresne
Copy link
Contributor

I think it would be overall simpler maintenance to follow Django's lead and drop support for Python 2. It is very close to EOL anyway. It will required fewer compatibility shims and workarounds. Work for this has started #709

@codingjoe
Copy link

Thanks for addressing this issue. I guess it blocked some people from testing the Django alpha.

Thanks for this, I'm not quite sure why they removed six before 1.11 is no longer supported. I think a better way to solve this is to do try except rather than depending on six.

@jschneier I understand the confusion, yet six has undergone the regular deprecation cycle, which wasn't required, considering that it was never part of the official Django API.

I think it would be overall simpler maintenance to follow Django's lead and drop support for Python 2. It is very close to EOL anyway. It will required fewer compatibility shims and workarounds. Work for this has started #709

@jdufresne I second that. I believe there is no need to wait until 1.11 hits EOL in April, since 1.11 extended support does not cover Python 2.7 since it's EOL is in December. So one should only use Django 1.11 on Python 3 after December.

It's absolutely admirable to keep support Python 2 for that long, but I guess it's time for django-storages v2.0.0 ;)

@jschneier
Copy link
Owner

jschneier commented Sep 27, 2019

This library saw such a dearth of development for such a long time that I am attempting to put in all the minimum necessary features before doing something drastic and breaking backwards compat too strongly. When I release 2.0 I think we will also move to strict semantic versioning - given where we started I found it impractical to start there. I understand the EOL timeline, however.

@codingjoe
Copy link

@jschneier I hear you. If you need any help, you just say the word. Thanks for maintaining this beast, much appreciated.

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 this pull request may close these issues.

Support django 3.0
4 participants