Develop Reference

Instance of 'SQLAlchemy' has no 'Column' member (no-member)

I'm currently trying to implement steam login into website. But I'm unable to get pass this error within the code. I've created the database object but it keeps showing the error I mentioned earlier. I'm not sure whether SQLAlchemy has changed or what since I used it.
from flask import Flask
from flask_sqlalchemy import SQLAlchemy
app = Flask(__name__)
db = SQLAlchemy(app)
class User(db.Model):
id = db.Column(db.Integer, primary_key=True)
The message emitted by pylint is
E1101: Instance of 'SQLAlchemy' has no 'Column' member (no-member)

EDIT: After read and try np8's answer my previous answer is wrong there is a package you have to install, which is pylint_flask_sqlalchemy
so the answer will be
on your project directory find folder .vscode (if you dont have it, just create it) then create file settings.json and add this line
{
# You have to put it in this order to make it works
"python.linting.pylintArgs": [
"--load-plugins",
"pylint_flask_sqlalchemy",
"pylint_flask", # This package is optional
]
}
You also need to have pylint-flask-sqlalchemy and if you want to use pylint-flask install on your current python environment:
pip install pylint-flask-sqlalchemy
pip install pylint-flask

pip install pylint-flask
In case of Visual Studio Code: Open File > Preferences > Settings > Edit in settings.json as below:
"python.linting.pylintArgs": ["--load-plugins", "pylint_flask"]

Summary of working and non-working configurations
It seems that this can be configured so many ways incorrectly, that I decided to write the different options down. I am assuming VS Code, but for command line or other editor, arguments and their order is the same. These were tested using the latest versions of all the packages (list in the bottom of this post)
Working versions
# What you'll need is pylint_flask_sqlalchemy
"python.linting.pylintArgs": ["--load-plugins", "pylint_flask_sqlalchemy"]
# You can add pylint_flask but only if it is *AFTER* pylint_flask_sqlalchemy
"python.linting.pylintArgs": ["--load-plugins", "pylint_flask_sqlalchemy", "pylint_flask"]
Non-working versions
# pylint_flask does not help, but can break it (see below)
"python.linting.pylintArgs": ["--load-plugins", "pylint_flask"]
# You can NOT add pylint_flask *BEFORE* pylint_flask_sqlalchemy
"python.linting.pylintArgs": ["--load-plugins", "pylint_flask", "pylint_flask_sqlalchemy"]
# CAUTION: These will disable pylint silently altogether!
# Do not use dash (-) but underscore (_)!
"python.linting.pylintArgs": ["--load-plugins", "pylint-flask-sqlalchemy", "pylint-flask"]
"python.linting.pylintArgs": ["--load-plugins", "pylint-flask"]
"python.linting.pylintArgs": ["--load-plugins", "pylint-flask-sqlalchemy"]
Details for those who are interested
pylint_flask_sqlalchemy
The pylint-flask-sqlalchemy1 was created specifically to fix this2. You can enable it by adding it to --load-plugins of pylint. In command line this would be
python -m pylint --load-plugins pylint_flash_sqlalchemy <mymodule.py>
and in VS Code (Settings (JSON)):
"python.linting.pylintArgs": ["--load-plugins", "pylint_flask_sqlalchemy"]
1Also mirrored to GitHub: https://github.com/anybox/pylint_flask_sqlalchemy
2See this comment on pylint Issue tracker.
pylint_flask
pylint-flask is pylint plugin for Flask. It has nothing to do with Flask-SQLAlchemy and it does not even try to solve the false positive issues pylint has with Flask-SQLAlchemy3. The only possibility to use pylint-flask to "make the errors disappear" is to load it with erroneusly with dashes, which makes the whole pylint to be disabled.
It seems that pylint-flask must be loaded after pylint-flas-sqlalchemy; I tested with my setup, and for some reason
"python.linting.pylintArgs": ["--load-plugins", "pylint_flask", "pylint_flask_sqlalchemy"]
will not work, but
"python.linting.pylintArgs": ["--load-plugins", "pylint_flask_sqlalchemy", "pylint_flask"]
will. So the order of loading plugins matters.
3 See the code for yourself: pylint-flask source & pylint-flask-sqlaclhemy source
Caution: Do not remove your linting accidentally
As the documentation of pylint-flask and pylint-flask-sqlalchemy says, the names in the argument --load-plugins should be written with underscores; If you use
"python.linting.pylintArgs": ["--load-plugins", "pylint-flask", "pylint-flask-sqlalchemy"]
in VS Code, the errors will be gone, but so will be all of your linting as the pylint crashes silently in the background.
Installing pylint-flask-sqlalchemy
pip install pylint-flask-sqlalchemy
Used versions
Flask 1.1.2
Flask-SQLAlchemy 2.4.4
pylint 2.5.3
pylint-flask 0.6
pylint-flask-sqlalchemy 0.2.0
See also
Discussion on pylint GitHub issue: "Problem with Flask-SQLAlchemy, cannot find valid and existing property in SQLAlchemy object."

Open the Command Palette (Command+Shift+P on macOS and Ctrl+Shift+P on Windows/Linux) and type in one of the following commands:
Python: Select Linter
Switch from PyLint to flake8 or other supported linters.

I've just encountered this issue. Neither of the suggested solutions worked for me, but the following does.
First, install these modules:
pip install pylint-flask
pip install pylint-flask-sqlalchemy
Then, in Visual Studio Code, you need to add the following to your settings.json file:
"python.linting.pylintArgs": ["--load-plugins", "pylint-flask", "pylint-flask-sqlalchemy"]

For Windows, this works: In case of Visual Studio Code: Open File > Preferences > Settings > Edit in settings.json ->
and add this code after comma below existing settings:
"python.linting.pylintArgs": [
"--load-plugins",
"pylint-flask"
]

How to deal with staticfiles module in an old version of django?

I want to deploy my app developed with django 1.2.5 and I have a list of required packages, I have installed them and when I launch http://localhost:8000 I get the following error:
from ckeditor.widgets import CKEditorWidget
File "build\bdist.win32\egg\ckeditor\widgets.py", line 4, in <module>
ImportError: No module named staticfiles.templatetags.staticfiles
I have installed a package called: django-ckeditor 4.4.8 and it seems to be the root cause, I have seen the ckeditor\widgets.py file and trying to modify it but no chance (because of compilation in an egg file):
#ckeditor\widgets.py
from django.contrib.staticfiles.templatetags.staticfiles import static
...
try:
js += (
static('ckeditor/ckeditor/ckeditor.js'),
static('ckeditor/ckeditor-init.js'),
)
any workaround for this issue?

Firstly, you should really upgrade your app to a later version of Django. Django 1.2 is over 5 years old and has not received security updates for years.
It looks like the line that is causing you problems has been reverted in master. So you could try the previous version 4.4.7 or wait for the next release.

How to suppress the deprecation warnings in Django?

Every time I'm using the django-admin command — even on TAB–completion — it throws a RemovedInDjango19Warning (and a lot more if I use the test command). How can I suppress those warnings?
I'm using Django 1.8 with Python 3.4 (in a virtual environment). As far as I can tell, all those warnings come from libraries not from my code.
Examples
Here are some examples:
…/lib/python3.4/importlib/_bootstrap.py:321: RemovedInDjango19Warning: django.contrib.contenttypes.generic is deprecated and will be removed in Django 1.9. Its contents have been moved to the fields, forms, and admin submodules of django.contrib.contenttypes.
return f(*args, **kwds)
…/lib/python3.4/site-packages/django/contrib/admin/util.py:7: RemovedInDjango19Warning: The django.contrib.admin.util module has been renamed. Use django.contrib.admin.utils instead.
"Use django.contrib.admin.utils instead.", RemovedInDjango19Warning)
…/lib/python3.4/site-packages/django/templatetags/future.py:25: RemovedInDjango19Warning: Loading the ``url`` tag from the ``future`` library is deprecated and will be removed in Django 1.9. Use the default ``url`` tag instead.
RemovedInDjango19Warning)
Update
Since Django version 1.11 (release notes) deprecating warnings are no longer loud by default. So I guess this won't be an issue anymore, since 1.11 is the last version to support Python 2 and also features long-term support.

Adding a logging filter to settings.py can suppress these console warnings (at least for manage.py commands in Django 1.7, Python 3.4).
A filter can selectively suppress warnings. The following code creates a new "suppress_deprecated" filter for the console and appends it to the default logging filters. Add this block to settings.py to configure the LOGGING variable:
import logging, copy
from django.utils.log import DEFAULT_LOGGING
LOGGING = copy.deepcopy(DEFAULT_LOGGING)
LOGGING['filters']['suppress_deprecated'] = {
'()': 'mysite.settings.SuppressDeprecated'
}
LOGGING['handlers']['console']['filters'].append('suppress_deprecated')
class SuppressDeprecated(logging.Filter):
def filter(self, record):
WARNINGS_TO_SUPPRESS = [
'RemovedInDjango18Warning',
'RemovedInDjango19Warning'
]
# Return false to suppress message.
return not any([warn in record.getMessage() for warn in WARNINGS_TO_SUPPRESS])
The 'mysite.settings.SuppressDeprecated' string needs to change if the root website module (or filter location and/or name) is different.

In django 1.7, a new setting was introduced SILENCED_SYSTEM_CHECKS to suppress warnings
A list of identifiers of messages generated by the system check
framework (i.e. ["models.W001"]) that you wish to permanently
acknowledge and ignore. Silenced warnings will no longer be output to
the console; silenced errors will still be printed, but will not
prevent management commands from running.
Documentation could be found here
Here is a list of all the checks to suppress
Example:
If you wish to suppress the TEMPLATES_ warning,
The standalone TEMPLATE_* settings were deprecated in Django 1.8
your settings would be:
SILENCED_SYSTEM_CHECKS = ["1_8.W001"]

I'll leave this for newcomers:
As for django 1.11 deprecating warnings are no longer loud by default. To activate them run python -Wd manage.py runserver for example.
source

In manage.py, add this to the top line --
#!/usr/bin/env PYTHONWARNINGS=ignore python
This will suppress all warnings, which I agree can in some situations be undesirable if you're using a lot of third party libraries.
Disclaimer: Recommended only after you've already seen the warnings at least 1,000 too many times already, and should be removed when you upgrade Django.
Note: this may have some undesirable effects on some platforms, eg swallowing more output than just warnings.

Nothing of the above have worked for me, django 1.9. I fixed this by adding the following lines to settings.py:
import logging
def filter_deprecation_warnings(record):
warnings_to_suppress = [
'RemovedInDjango110Warning'
]
# Return false to suppress message.
return not any([warn in record.getMessage()
for warn in warnings_to_suppress])
warn_logger = logging.getLogger('py.warnings')
warn_logger.addFilter(filter_deprecation_warnings)

While reviewing deprecation warnings in other dependencies of my Django 1.8 project, using
python -Wd manage.py runserver
, I was able to filter out Django deprecation warnings by temporarily adding
import warnings
from django.utils.deprecation import RemovedInDjango110Warning
warnings.filterwarnings(action="ignore", category=RemovedInDjango110Warning)
to my settings.py (can presumably be in any module that's loaded at startup). I couldn't figure out how to include the filter as an extra -W option, i.e.
python -Wd -Wi::RemovedInDjango110Warning manage.py runserver
resulted in Invalid -W option ignored: unknown warning category: 'RemovedInDjango110Warning'.

For a quick command-line interface only solution, preface manage.py with python -W ignore when executing, as in:
python -W ignore manage.py runserver
-or-
python -W ignore manage.py shell_plus
-or-
python -W ignore manage.py makemigrations
This is working for me now, to suppress all of the Django 1.10 deprecation warnings while running Django 1.9.

For some reason the solution provided by Fred Schleifer didn't work for me in Django 1.9, so I had to find a different solution.
In settings.py, I set up a custom LOGGING_CONFIG function:
LOGGING_CONFIG = 'my_project.logging_utils.configure'
Then I defined my custom my_project.logging_utils module like so:
from logging.config import dictConfig
import warnings
from django.utils.deprecation import RemovedInDjango110Warning
IGNORE_DJANGO_110_WARNINGS = {
# This is a specific warning raised by a third-party library.
r'rest_framework_swagger\.urls': r'django\.conf\.urls\.patterns\(\) is deprecated.*'
}
def configure(settings):
dictConfig(settings)
for module, message in IGNORE_DJANGO_110_WARNINGS.items():
warnings.filterwarnings(
action='ignore',
category=RemovedInDjango110Warning,
module=module,
message=message
)
The IGNORE_DJANGO_110_WARNINGS dict contains a mapping from module names to regular expressions of warnings raised by them. I chose to be very specific in the kinds of warnings I suppressed, as I still wanted to see ones that I didn't expect. As individual third-party libraries are updated, I'll remove their associated entries from the dict.

# in settings.py
import warnings
from django.utils.deprecation import RemovedInDjango20Warning
DEBUG = True
if DEBUG:
warnings.simplefilter('default')
warnings.filterwarnings('ignore', category=RemovedInDjango20Warning)
# use it if you annoyed by DeprecationWarning
warnings.filterwarnings('ignore', category=DeprecationWarning)

This standart django script add TAB–completion for you bash - https://github.com/django/django/blob/master/extras/django_bash_completion
PYTHONWARNINGS is not defined - error in console. Add export PYTHONWARNINGS="ignore" and unset PYTHONWARNINGS in _django_completion()
Original function:
_django_completion()
{
COMPREPLY=( $( COMP_WORDS="${COMP_WORDS[*]}" \
COMP_CWORD=$COMP_CWORD \
DJANGO_AUTO_COMPLETE=1 $1 ) )
}
My version. Do not break the basic behavior in other cases.
_django_completion()
{
export PYTHONWARNINGS="ignore"
COMPREPLY=( $( COMP_WORDS="${COMP_WORDS[*]}" \
COMP_CWORD=$COMP_CWORD \
DJANGO_AUTO_COMPLETE=1 $1 ) )
unset PYTHONWARNINGS
}

Django puts warnings through the standard python warnings module. If your python project throws warnings and they're "acceptable" for the moment, just use warnings.filterwarnings() or warnings.simplefilter(). I'm not sure where the "best" place for these are, but I've dropped them into my common_settings.py file (For me, this is a unchanging, checked-in file, that is imported by local_settings.py).
Eg:
warnings.filterwarnings(action="ignore", category=RemovedInDjango110Warning, module='django.template.utils', lineno=37)
Alas the comment about silencing the system checks won't work, here, since your example isn't throwing a system-check error.

I currently encounter this same issue when using Django 1.8. Instead of completely suppress those warnings, we decide to show them only in DEBUG mode.
We can add console handler in logging settings and use this handler to catch py.warnings. Here is the code snippet,
'filters': {
'require_debug_true': {
'()': 'django.utils.log.RequireDebugTrue'
},
...
},
'handlers': {
'console': {
'level': 'DEBUG',
'filters': ['require_debug_true'],
'class': 'logging.StreamHandler',
'formatter': 'standard',
},
...
},
'loggers': {
'py.warnings': {
'handlers': ['console', ],
'level': 'INFO',
'propagate': False
},
...
}
The complete Django settings file: https://github.com/haiwen/seahub/blob/21c827c68047e13700fe102d22a3f5515b22af89/seahub/settings.py#L484

Time to add another one suggestion here, which worked for me. Django 3.2, but should work on any version.
What worked for me is assuming that the developers would be clever enough to output these to python stderr, not stdout. They were!
So..., just redirect stderr to via a standard bash 2>/dev/null
django-admin findstatic teststatic.css 2>/dev/null
Found 'teststatic.css' here:
/Users/me/kds2/py2/bemyerp/websec/static/websec/nodelinks/teststatic.css
/Users/me/kds2/py2/bemyerp/dist/teststatic.css
Of course, bear in mind your context and what this redirection does: suppressing ANY error message. For example, if django-admin is missing, that error message will also disappear (run missing-django-admin findstatic teststatic.css 2>/dev/null to see the effect).
what I was trying to filter out...
HINT: Use django.db.models.JSONField instead.
pssystem.TagType: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the AppConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
Found 'teststatic.css' here:
/Users/me/kds2/py2/bemyerp/websec/static/websec/nodelinks/teststatic.css
/Users/me/kds2/py2/bemyerp/dist/teststatic.css
Things tried without success:
(I am not saying these never work, only that they didn't filter the particular messages I was getting and wanted to avoid, in my environment.
python -W ignore manage.py findstatic teststatic.css
PYTHONWARNINGS=ignore django-admin findstatic teststatic.css
PYTHONWARNINGS=ignore python manage.py findstatic teststatic.css
python -Wd manage.py findstatic teststatic.css
env: Django 3.2, using Python 3.10 with virtualenv

buildout configuration issue for my django project,not get specified version of django

I installed zc.buildout using easy_install. I used the tutorial at http://jacobian.org/writing/django-apps-with-buildout/.
My problem is,
am not able to install the versions specified in the buildout.cfg:
[buildout]
parts = python
django
develop = .
versions = versions
eggs = nltk
html5lib
pysolr
python-openid
django-shorturls
[versions]
django = 1.4.1
[python]
recipe = zc.recipe.egg
interpreter = python
eggs = ${buildout:eggs}
[django]
recipe = djangorecipe
When I try ./bin/python
>>> import pysolr
>>> pysolr # it worked from my buildout
<module 'pysolr' from '/home/builout-tests/sandbox/eggs/pysolr-3.0.4-py2.7.egg/pysolr.pyc'>
>>> import django
>>> django.VERSION
(1, 3, 1, 'final', 0) # its my django version in system's python dist-packages
>>> django
<module 'django' from '/usr/lib/python2.7/dist-packages/django/__init__.pyc'>
And also how can I keep different versions of python, django, pylsolr, nltk, etc. for development and production versions?

Try replacing django by Django (with a caps D) in your [versions] section

The eggs you specify in your [buildout] part don't really do anything. It is common practice to put eggs there that you need in a couple of parts, like [python] and [django] in your case.
So... fix number one is to add eggs = ${buildout:eggs} to your [django] part, as that's probably what you intend.
Regarding the django/Django upper/lowercase version: there are two solutions for it. If you use a pre-2.0 buildout version, add extension = buildout-versions to your [buildout] part. It prints versions it picked and it removes the case sensitiveness.
Best option, though, is to use the latest 2.0 buildout. You probably have to download a fresh bootstrap.py from http://downloads.buildout.org/2/bootstrap.py and re-run bootstrap and bin/buildout. This also removes case insensitiveness. For more clarity, add show-picked-versions = true to your [buildout] part to get a nice listing of picked versions. Way easier to spot weirdness and unexpected behaviour that way :-)

Django: manage.py ImportError because environment variable is undefined

I've just cloned a Django project using Mercurial to a Windows machine that I have set up Python 2.7 on. When I try to run manage.py (with or without a command), I get the following error:
Traceback (most recent call last):
File "C:\Users\jes.000\Documents\project\manage.py", line 30, in <module>
import django.core.servers.basehttp
File "C:\Python27\lib\site-packages\django\core\servers\basehttp.py", line 26, in <module>
from django.views import static
File "C:\Python27\lib\site-packages\django\views\static.py", line 95, in <module>
template_translatable = ugettext_noop(u"Index of %(directory)s")
File "C:\Python27\lib\site-packages\django\utils\translation\__init__.py", line 75, in gettext_noop
return _trans.gettext_noop(message)
File "C:\Python27\lib\site-packages\django\utils\translation\__init__.py", line 48, in __getattr__
if settings.USE_I18N:
File "C:\Python27\lib\site-packages\django\utils\functional.py", line 184, in inner
self._setup()
File "C:\Python27\lib\site-packages\django\conf\__init__.py", line 40, in _setup
raise ImportError("Settings cannot be imported, because environment variable %s is undefined." %ENVIRONMENT_VARIABLE)
ImportError: Settings cannot be imported, because environment variable DJANGO_SETTINGS_MODULE is undefined.
I understand that manage.py is supposed to set that environment variable. I also understand that I might be getting this error because the project is not in the python path... but adding it manually seems like it shouldn't be necessary. Isn't manage.py supposed to resolve this issue as well?
Edit: I've just tested and found that it does the exact same thing under Linux.
Edit: Here's a useful discovery: I only get this error if I install Django via PIP, it works fine if I install the python-django package on Ubuntu. So there's something that the debian package is doing that PIP isn't. Maybe the debian package sets some environment variables? I need to figure that out, since I'm trying to develop on Windows.
Edit: I think I've found the problem, but not a solution. Working on an Ubuntu machine, when I install Django via PIP (pip install django), this project doesn't work with the error I gave. If I create a new project (django-admin startproject testproject) and try that it works, and it consists of manage.py in the created folder, with another folder that contains everything else. Like this:
+-testproject
+-manage.py
+-testproject
+-__init__.py
+-etc.
When I install the Debian package (apt-get install python-django) the project I'm trying to work on works, and if I create a test project (django-admin startproject testproject) it has a folder structure like this:
+-testproject
+-manage.py
+-__init__.py
+-etc.
Notice the difference: the PIP Django package seems to put the manage.py outside of the python module that is the app, while the Debian package puts manage.py inside the module. I assume that this is due to the two packages being of a different version of Django, in between which they changed the structure, because the two packages doing this differently doesn't make any sense.
So my problem is that the project I'm trying to develop was originally generated using the version that's been Debian packaged, while on my Windows machine I'm trying to use the version of Django from pip.
The trouble is that I'm not certain how to fix the problem. Naively moving the manage.py up a directory so it's above the project folder doesn't work, because this 'debian-package version' manage.py tries to just import settings, which fails if it's not in the same folder as settings.py. But somewhere else in Django, something seems to be expecting the project itself to be at //settings.py (as would be the case if the pip version of django-admin was used) rather than at /settings.py (as is the case if the debian-package version is used).
If I look it up, the version in the Ubuntu repositories is 1.3.1, while the version in PyPI is 1.4. Look at the release notes for 1.4, and hey:
An updated default project layout and manage.py that removes the
“magic” from prior versions. And for those who don’t like the new
layout, you can use custom project and app templates instead!
But... shouldn't projects generated with the 1.3 layout still work under 1.4..?

I'm not sure if this has changed in more recent version of django, but the default manage.py simply tries to import the settings.py file and start the manager. You would be expected to put the project in your PYTHONPATH, or to put the settings.py into your DJANGO_SETTINGS_MODULE variable, by default.
You can modify the manage.py to be a bit smarter with this snippet:
manage.py
#!/usr/bin/env python
from django.core.management import execute_manager
...
import settings
import os
project = os.path.basename(os.path.dirname(__file__))
os.environ['DJANGO_SETTINGS_MODULE'] = '%s.settings' % project
if __name__ == "__main__":
execute_manager(settings)
Now you can run manage.py from any location, since it will always explicitly set up the path to the settings.py file.

You may add the following code to the file manage.py ,like this:
from django.conf import settings
settings.configure()

This is indeed due to the difference in default layouts between 1.3 and 1.4. Normally Django 1.3 projects will work under 1.4, so something else is going on here that I can't quite figure out. I have established that the problem isn't platform-dependent.
I couldn't figure out the exact problem but I did figure out a fix. That was:
Create a new project under Django 1.4 and poach its manage.py file. After changing the project name, this file works as a manage.py. I named it 'manage14.py' so that the original manage.py would be left for my colleagues using Django 1.3.
Add the directory above the one that the project was in to the global PYTHONPATH. This is not an ideal solution, but it allowed an unmodified Django 1.4 manage.py to load the project without having to convert the project to Django 1.4's organization.
As soon a practical, I plan to convert the project to the Django 1.4 format since it seems to be better anyway, particularly from the perspective of avoiding this kind of problem. Unfortunately I'll have to wait until the Ubuntu repo's get 1.4 so that my colleagues will be up to the same version I am on Windows using PyPI.