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"
]

AttributeError: 'Nonetype' object has no attribute '_info'

I am working on a Django project and this error arises when I try to run any management commands such as:
python manage.py validate --settings ord.settings.development, python manage.py syncdb --settings ord.settings.development. The project uses Django 1.5 The error is: AttributeError: 'Nonetype' object has no attribute '_info'. No other output is given.
The project base settings file is: https://gist.github.com/anonymous/5c0fede63b2724d7880b
The development settings: https://gist.github.com/anonymous/f60b90dcf573b0a7b920
I have replaced sensitive settings with x
Any idea what could be wrong?
Some extra info, when i comment out the LANGUAGE_CODE settings, some commands like validate, runserver, shell run fine but syncdb and migrate fail with error: DatabaseError: current transaction is aborted, commands ignored until end of transaction block
Traceback: https://gist.github.com/anonymous/bc3364ae5ba511566871

Had the same issue,
Please follow the steps:
go to django/utils/translation/trans_real.py
search for res = _translation(globalpath)
Add the following:
if res is None:
return gettext_module.NullTranslations()
source: https://code.djangoproject.com/ticket/18192

Had the same problem with a new installation on ubuntu 14.04.
After lots of digging - thought I should share my finding:
We are using django 1.5 and had the same error. It appears that the django installation was missing the folder django/conf/locale/en/LC_MESSAGES
Solution was to install latest version "pip install django==1.5.12"

I have been getting this error with a virtualenv setup.
I noticed that pip was installing some parts of Django in the wrong place in my virtualenv - it was being installed in the top level folder of the virtualenv instead of in lib/python2.7/site-packages/
Anyway, I followed the advice on this answer, which involves clearing a corrupted pip cache:
pip and virtualenv installing parts of django in the wrong place
After that Django installed to the correct location and the error was gone.

after formating my laptop, my Django projects doesn't work

Before I format my laptop, I cut & paste my Django project (folder that include mysite and myvenv folders) to another partition. It was built on python 2.7 and used virtual environment and Django 1.7.
Now I have python 3.4, and after activating virtual environment and run:
$ python manage.py makemigrations
I get this error:
Traceback (most recent call last):
File "manage.py", line 12, in <module>
from django.core.management import execute_from_command_line
ImportError: No module named django.core.management
So I tried and installed python2.7 but still get the same error.
Is there a way to correct what happend to my project and if not I need your advice for best practise on how can I move Django project without break it?
In my Django project I followed the official tutorial on djangoproject.com
This is my first question on stackoverflow

I revoke my answer. I no longer want to support this site.

My guess would be that your manage.py is not configured properly. The first line must define the Python exec to run the script, and not another location like /user/bin/python. If it is set to /user/bin/python you will almost certainly have certain packages missing. Ensure that the path you specify is to your virtualenv python location.

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.

Setting up Django on an internal server (os.environ() not working as expected?)

I'm trying to setup Django on an internal company server. (No external connection to the Internet.)
Looking over the server setup documentation it appears that the "Running Django on a shared-hosting provider with Apache" method seems to be the most-likely to work in this situation.
Here's the server information:
Can't install mod_python
no root access
Server is SunOs 5.6
Python 2.5
Apache/2.0.46
I've installed Django (and flup) using the --prefix option (reading again I probably should've used --home, but at the moment it doesn't seem to matter)
I've added the .htaccess file and mysite.fcgi file to my root web directory as mentioned here.
When I run the mysite.fcgi script from the server I get my expected output (the correct site HTML output). But, it won't when trying to access it from a browser.
It seems that it may be a problem with the PYTHONPATH setting since I'm using the prefix option.
I've noticed that if I run mysite.fcgi from the command-line without setting the PYTHONPATH enviornment variable it throws the following error:
prompt$ python2.5 mysite.fcgi
ERROR:
No module named flup Unable to load
the flup package. In order to run
django as a FastCGI application, you
will need to get flup from
http://www.saddi.com/software/flup/
If you've already installed flup,
then make sure you have it in your
PYTHONPATH.
I've added sys.path.append(prefixpath) and os.environ['PYTHONPATH'] = prefixpath to mysite.fcgi, but if I set the enviornment variable to be empty on the command-line then run mysite.fcgi, I still get the above error.
Here are some command-line results:
>>> os.environ['PYTHONPATH'] = 'Null'
>>>
>>> os.system('echo $PYTHONPATH')
Null
>>> os.environ['PYTHONPATH'] = '/prefix/path'
>>>
>>> os.system('echo $PYTHONPATH')
/prefix/path
>>> exit()
prompt$ echo $PYTHONPATH
Null
It looks like Python is setting the variable OK, but the variable is only applicable inside of the script. Flup appears to be distributed as an .egg file, and my guess is that the egg implementation doesn't take into account variables added by os.environ['key'] = value (?) at least when installing via the --prefix option.
I'm not that familiar with .pth files, but it seems that the easy-install.pth file is the one that points to flup:
import sys; sys.__plen = len(sys.path)
./setuptools-0.6c6-py2.5.egg
./flup-1.0.1-py2.5.egg
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sy
s.path[p:p]=new; sys.__egginsert = p+len(new)
It looks like it's doing something funky, anyway to edit this or add something to my code so it will find flup?

In your settings you have to point go actual egg file, not directory where egg file is located. It should look something like:
sys.path.append('/path/to/flup/egg/flup-1.0.1-py2.5.egg')

Try using a utility called virtualenv. According to the official package page, "virtualenv is a tool to create isolated Python environments."
It'll take care of the PYTHONPATH stuff for you and make it easy to correctly install Django and flup.

Use site.addsitedir() not os.environ['PYTHONPATH'] or sys.path.append().
site.addsitedir interprets the .pth files. Modifying os.environ or sys.path does not. Not in a FastCGI environment anyway.
#!/user/bin/python2.6
import site
# adds a directory to sys.path and processes its .pth files
site.addsitedir('/path/to/local/prefix/site-packages/')
# avoids permissions error writing to system egg-cache
os.environ['PYTHON_EGG_CACHE'] = '/path/to/local/prefix/egg-cache'

To modify the PYTHONPATH from a python script you should use:
sys.path.append("prefixpath")
Try this instead of modifying with os.environ().
And I would recommend to run Django with mod_python instead of using FastCGI...