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
Made it django 1.6 and Python 3 compatible #281
Conversation
…moved the six dependency I had added in earlier. (It's built in to django)
…ion tests, and added a urlEqual function
…6 to zinnia.__init__. Corrected the previously-incorrect urlEqual function.
… previous corrections were bad.) Finally have gotten rid of all errors except for the querycount-related failures.
Hmm. I see the build failure. Looking at it now. |
… but apparently it causes issues there.
Okay. I tried to quickly hack it in, but clearly it's not going to work tonight. I'm going to work on setting up the buildout thing properly on my computer so I can replicate the issues the build runners are having so I can resolve them properly. Will fix some time tomorrow hopefully. Sorry about this. |
…st pep8 errors. Coverage seems to pass too, so hopefully this works...
Phew, finally done! Edit: Coverage is now reporting that coverage went down as a result of the change. As far as I can tell, the tests already included, if tested using 1.6, would suffice to cover the lines mentioned (the uncovered lines that were added as a result of my commits, that is). I'm not sure what to do about this. If something needs to be done, let me know what it is and I'll do my best to do it. |
…ed. Everything should be clean and in order now.
Bump? |
FYI I've merged this in my fork in order to get it to work in Django 1.6 / python 2.7.3 and it works fine. |
Issue 296 doesn't appear to be a result of my patch. Still, I'll try to look at it when I get a chance. |
Hi @marky1991, I will not automatically merge the pull request, because I have some details to review, like removing the compatibility support for Django 1.5. Here the plan to integrate your changes:
What do you think of this ? Regards |
"...like removing the compatibility support for Django 1.5." My patch doesn't remove support for 1.5. (If this isn't what you meant, ignore this) The same tests pass (or fail) in (python 2.6, django 1.5) and (py3.3, django 1.6). That plan sounds fine. I was just checking in. : ) |
Yes I see that you have ensured the compatibility with Django 1.5, but I don't want it. |
Oh, okay. I'll remove the compatability bits then. That'll make the code simpler anyway. |
As you wish, but I can do it myself during the integration process. PS: Good job on the Pearson's score, I think you have pointed out and fixed an historical issue. |
The tests are now fixed for Django 1.6 with Python 2. https://travis-ci.org/Fantomas42/django-blog-zinnia/builds/15096851 A replacement for django-tagging is now mandatory... |
With this version of django-tagging, https://github.com/Fantomas42/django-tagging, |
|
@bikeshedder I need to test more, but a first sight django-taggit does not do the job for me. I'm thinking about another solution, but this problematic needs to be developed in another topic. |
Pull-request merged in develop @ 49fa3c9 Thank @marky1991 Another time: really good job. |
With this patch, the app's tests all pass in django 1.6 and python 3.3. The only remaining failures are query-counting related tests (which I believe are a result of django-tagging being weird. See https://groups.google.com/forum/#!topic/django-blog-zinnia/LRUzSxLlHTM ), two tagging-related tests (I believe this is django-tagging's fault), and tests that import custom_url_shortener.py and custom_spam_checker.py . (Both of which do nothing but raise exceptions, guaranteeing the tests will fail.) The remaining failures fail when using the most recent version of 1.5, under python 2, and using the your most recent version of django-blog-zinnia, so they are not new regressions. I think they could most easily be fixed by replacing django-tagging with a better-supported tagging app. I'd like to address that and the related failures with a later patch.
Some key changes:
-Changes to how views/mixins/archives.py 's get_previous_next_published works.
-Replacement of explicit unicode calls with six.text_type calls.
-Changed how pearson_score works completely to match the algorithm found on the internet. The original version returned values that disagreed with wolfram's calculator. My updated version matches the online calculator's values.
-in preview.py, we now return str(self.preview) instead of the soup itself. (Returning a non-string in str in python 3 raises an exception)
-assert(Not)Equals calls converted to assert(Not)Equal to silence deprecation warnings
-a new urlEqual function was added in tests/utils.py . This is intended to compare urls that have querystrings, where ordering doesn't matter. (So two urls with querystrings in different order should still compare equal)
Some remaining questions:
-CategoryAdminForm in admin/forms.py may or may not be right. The code used originally is not a part of the API so it's not documented at all. (It's not even documented in the source...) The solution currently provided makes the code run and appears to work. (It's the best guess of me and some people on the django-users IRC channel)
-Why does the pearson_score function in comparison.py return 1-r instead of just r? (See the code for context)
-test_vector_builder in tests/comparison.py badly needs to be looked at. I've made it disregard ordering now. I'm not sure if this is desired or not. Right now, the code assumes a stable iteration order over dictionary keys, which is not a valid assumption. I've done my best to fix it, but I don't really know if it matches what you intended or not. If the function wants to preserve order, it needs to be completely rewritten.
-The changes to xmlrpc with respect to bytes vs. strings needs to be looked at. I think I did it correctly, but I'm not 100% sure. (Also tests/utils.py, TestTransport)