16👍
if you’re running Jython
import platform
platform.system()
return ‘Java’
here has some discussion, hope this helps.
42👍
The most clear-cut way is:
import platform
platform.python_implementation()
‘CPython’
By default, most of the time the underlying interpreter is CPython only which is also arguably the most efficient one 🙂
- How can I escape LaTeX special characters inside django templates?
- {% load static %} and {% load staticfiles %}: which is preferred?
26👍
As sunqiang pointed out
import platform
platform.system()
works for Jython 2.5, but this doesn’t work on Jython 2.2 (the previous Jython release). Also, there has been some discussion about returning more operating system specific details for calls like these in Jython 3.x. Nothing has been decided there, but to be safely backwards and forwards compatible, I would suggest using:
import sys
sys.platform.startswith('java')
Which will return True for Jython and False everywhere else (actually in Jython 2.2 or older it returns 1 for Jython and 0 everywhere else, but this will still work fine in if statements and other checks). This call works in Jython at least as far back as 2.1, and will work for the foreseeable future.
In Python versions 2.6 or above (note Jython 2.6 has not yet been released) another option is:
import platform
platform.python_implementation
Which returns ‘CPython’ for the C implementation of Python, ‘IronPython’ for IronPython and will return ‘Jython’ for Jython. Obviously this one isn’t backwards compatible below 2.6, but will be forwards compatible.
- Django difference between clear() and delete()
- Django request.user.is_superuser doesn't work
- Django queryset __contains case sensitive?
5👍
In Python 3.3 and beyond you can use sys.implementation and look at the name
attribute.
- Coverage in parallel for django tests
- Sphinx and re-usable Django apps
- Multiple lookup_fields for django rest framework
- SQL injection hacks and django
- Django test: TransactionManagementError: You can't execute queries until the end of the 'atomic' block
3👍
You’ll have unique settings.py for every different environment.
Your development settings.py should not be your QA/Test or production settings.py.
What we do is this.
We have a “master” settings.py that contains the installed apps and other items which don’t change much.
We have environment-specific files with names like settings_dev_win32.py
and settings_qa_linux2.py
and
‘settings_co_linux2.py`, etc.
Each of these environment-specific settings imports the “master” settings, and then overrides things like the DB driver. Since each settings file is unique to an environment, there are no if-statements and no detecting which environment we’re running in.
Production (in Apache, using mod_wsgi and mysql) uses the settings_prod_linux2.py
file and no other.
Development (in Windows using sqlite) uses the settings_dev_win32.py
file.
- Advanced Django Template Logic
- Best practice when using folium on django
- Variable not found. Declare it as envvar or define a default value
- Google.maps.event.addDomListener() is deprecated, use the standard addEventListener() method instead : Google Place autocomplete Error