I just started developing on Django, and then I thought using the Syntastic syntax checker on it would be a good idea.
The problem is that it complains about some things being wrong when, in fact, they aren't.
Examples:
For
from django.core.urlresolvers import reverse
I get:
error| [F0401] Unable to import 'django.core.urlresolvers'
For
amount = self.sale_set.filter(date__year=year).aggregate(sum=Sum('amount'))["sum"]
I get (where self is an Album)
error| [E1101, Album.get_sales_total] Instance of 'Album' has no 'sale_set' member
This code runs perfectly even with these "errors", but how can I make Syntastic behave correctly?
piggybacking on #supervacuo's answer:
there is a way to get this working for syntastic and it's rather straightforward, if not easy to figure out for someone unfamiliar with syntastic options (like, say, me):
in your .vimrc, add this line:
let g:syntastic_python_pylint_args = "--load-plugins pylint_django"
of course, this does require pylint-django be installed in your environment
Both of these messages come from pylint — you can see fuller explanations with pylint --help-msg=$ID, or on http://pylint-messages.wikidot.com/.
You can disable the checks with e.g. from django.core.urlresolvers import reverse
# pylint: disable=F0401, but that gets tiresome pretty quickly.
There's a pylint plugin for Django which will definitely fix your E1101 (and I hope the F0401 too). Maybe have a go at installing the plugin and configuring Syntastic to use it?
Related
I am moving a Django project from django-hvad to django-parler during a Django upgrade process.
In django-parler the API is almost the same as django-hvad and when I just replace the from hvad.something import Something it just works fine but I couldn't find an equivalent for translatable_modelform_factory
It does not exist in their documentation. Anybody has an idea on what can I use instead of this function and how can I use it? Thanks in advance.
I found an answer and I put it here in case anyone searches for it in the future:
django-parler uses TranslatableModelForm class instead of translatable_modelform_factory function and it takes exactly the same arguments.
I have a Django-CMS 2.4.1 project that always gives me the warning:
DeprecationWarning: Implicit manager CMSPlugin.tree will be removed in django-mptt 0.6. Explicitly define a TreeManager() on your model to remove this warning.
This only occurs in production - not in dev.
I tried:
./manage.py cms fix-mptt
which gives me the output (after the same warning as above):
fixing mptt page tree
fixing mptt plugin tree
all done
But... this does not solve the problem, e.g. if I repeat the command it does the same thing again, with the same warning.
The warning doesn't seem to be doing any harm yet, but I imagine it will with the next version of django-mptt. Can anyone give me any advice?
thanks
Harmless but utterly annoying, make the b*tch shut up:
CMSPlugin.tree = CMSPlugin.objects
in any module of early execution (models.py for example).
You can safely ignore that warning in any case.
It's just telling you that django CMS's use of Django MPTT is relying on something that will be removed in a future version.
EDIT I miscounted - it is printed out twice, not four times.
I put this in my settings.py
print 'ola!'
and on startup "ola" is printed out twice! This seems like something is wrong with my pycharm django project ... any ideas why this would happen? It isn't in a loop or anything (that i'm aware of, anyway)
cheers!
YAY The user known only as "rohit", as per the comments, has determined that a solution can be found here: https://stackoverflow.com/a/2110584/1061426 ~ see the comment about disabling reloading.
CAUTION I don't have my Django code up and about now, so I don't know what the noload will do. Good luck, soldiers.
If you print out the thread ID within settings.py, you will see that settings.py is actually being loaded on two different threads.
See this stackoverflow response and this article for more info.
Actually what Django does is putting a wrapper around settings. It is basically an object (settings object if you want so) which give you access to some direct setters like settings.WHATEVER, so it appears like you access the global variables in settings.py direclty.
I really don't remember though, why the import happens twice. I looked into it once when I worked on django-dynamic-settings which uses a very similar approach as Django itself.
Anyway, if you are interested in the "magic" you can follow the flow starting from the execute_from_command_line call in manage.py.
Django does some strange things with settings.py, and it will execute more than once. I'm used to seeing it imported twice, not sure why in PyCharm you're getting four times. You have to be careful with statements with side-effects in settings.py.
A closely-related question has been asked at least twice since. I can add that a Django core developer rejected the idea that this is any sort of Django bug; it's normal behavior.
Also see this from Graham Dumpleton.
I like Eclipse for a number of reasons. One of them is, when I'm doing a java project, I can copy and paste my project or rename it, to make a new one, and it will update all the names of everything.
I'm trying to do something similar for a django project.
I can set an APPNAME variable with the following code
APPNAME = os.path.basename(os.path.dirname(__file__))
and then I could import this in any file that needed to know the name of the application. This isn't an ideal solution however but it would work for my settings.py file as well as my urls.py files.
It won't work for situations where I need to import something from somewhere like so:
from myproject.someapp import forms
Is there a way for django/python to know what "myproject" is? Or can I use an import statement relative to the current app?
Or maybe there's a better way to copy django projects.
EDIT: I imagine there are also database dependencies as well that I'd have to deal with.
I follow a couple of rules to keep my applications portable. I'll list them below in the hope that someone finds them useful.
Include my apps in the PYTHONPATH rather than my projects. This way I can execute from app import forms rather than from project.app ....
Following #1, I always import from app only. This means I can reuse my apps in other projects without having to change import statements within the app or in other dependent apps.
If you stick to #1 and #2 you can generally copy and paste projects without too much trouble. You'll still have to modify settings.py though.
Sometimes when I run manage.py I get a cryptic message in red that says Error: cannot import name <Name> and nothing else.
Obviously, this is a simple import or syntax error and with a little looking around, I can usually fix it. Other times however it takes me quite a while to figure out what exactly I did wrong. Is there a way to get Django to spit out more info in this situation?
This is an annoying problem. Luckily, it's been fixed (recently): see this ticket and this patch.
If you want to just hack your local django install (you're running under virtualenv or buildout, right?), change to the root of your django directory (the one with README, INSTALL, etc) and run this:
curl "https://code.djangoproject.com/changeset/17197?format=diff&new=17197" | patch -p3\
So, if you run django trunk > 17197, apply the patch to your django install (it applied to django 1.2 for me), or wait until django 1.4, you'll be able to do this:
./manage.py shell --traceback
And you'll get a full traceback instead of just the Error: cannot import ...
Voila!
this happens when a circular import appears, when one model is dependent on another and in turn they try and import each other while executing code.
You might want to paste the two models that are causing you issues.
That'll help us debug.
Also it tends to happen sometimes with signals so if you have a signals file please paste too.