Redhat proposes placing a file in /etc/profile.d, i.e. for python:

$ cat /etc/profile.d/enablepython33.sh
#!/bin/bash
source scl_source enable python33

As this works for the devtools under centos for me you could try this.

An alternative of source /opt/rh/devtoolset-4/enable is

source scl_source enable devtoolset-4

The above shell script scl_source is more elegant than using a hard coded path (may be different on another machine). However scl_source does less because /opt/rh/devtoolset-4/enable uses scl_source and other stuff.

To use scl_source you may have to upgrade package scl-utils

yum update scl-utils  # old scl-utils versions miss scl_source

Quick copy-paste

echo 'source scl_source enable devtoolset-4' >> ~/.bashrc
    # Do not forget to change the version ↑

Source code for curious people

An example of scl_source source code:
https://gist.github.com/bkabrda/6435016

The scl_source installed on my Red Hat 7.1

#!/bin/bash

_scl_source_help="Usage: source scl_source <action> [<collection> ...]

Don't use this script outside of SCL scriptlets!

Options:
    -h, --help    display this help and exit"

if [ $# -eq 0 -o $1 = "-h" -o $1 = "--help" ]; then
    echo "$_scl_source_help"
    return 0
fi


if [ -z "$_recursion" ]; then
    _recursion="false"
fi
if [ -z "$_scl_scriptlet_name" ]; then
    # The only allowed action in the case of recursion is the same
    # as was the original
    _scl_scriptlet_name=$1
fi
shift 1

if [ -z "$_scl_dir" ]; then
    # No need to re-define the directory twice
    _scl_dir=/etc/scl/conf
    if [ ! -e $_scl_dir ]; then
        _scl_dir=/etc/scl/prefixes
    fi
fi

for arg in "$@"; do
    _scl_prefix_file=$_scl_dir/$arg
    _scl_prefix=`cat $_scl_prefix_file 2> /dev/null`
    if [ $? -ne 0 ]; then
        echo "Can't read $_scl_prefix_file, $arg is probably not installed."
        return 1
    fi

    # First check if the collection is already in the list
    # of collections to be enabled
    for scl in ${_scls[@]}; do
        if [ scl ]; then
            continue 2
        fi
    done

    # Now check if the collection isn't already enabled
    /usr/bin/scl_enabled $arg > /dev/null 2> /dev/null
    if [ $? -ne 0 ]; then
        _scls+=($arg)
        _scl_prefixes+=($_scl_prefix)
    fi;
done

if [ $_recursion == "false" ]; then
    _i=0
    _recursion="true"
    while [ {#_scls[@]} ]; do
        _scl_scriptlet_path="${_scl_prefixes[$_i]}/${_scls[$_i]}/${_scl_scriptlet_name}"
        source "$_scl_scriptlet_path"
        if [ $? -ne 0 ]; then
            echo "Can't source $_scl_scriptlet_name, skipping."
        else
            export X_SCLS="${_scls[$_i]} $X_SCLS"
        fi;
        _i=_i+1))
    done
    _scls=()
    _scl_prefixes=()
    _scl_scriptlet_name=""
    _recursion="false"
fi

This option sounds dangerous to me for root. I would think something like the following would be safer and more appropriate:

You can create a function that takes command line options. Think of this as an alias on steroids. Add the following to your .bashrc

python27() {
scl enable python27 “python $*”
}

Then test:

python27 –version
Python 2.7.5

This doesn’t help with your magic line in scripts, but will make it easier to call scripts:

[smccarty@keith ~]$ cat script.py
#!/usr/bin/env python27

import sys

print “Hello, World!”, sys.version

Call it normal and notice, the default installation of python is used:

[smccarty@keith ~]$ ./script.py
Hello, World! 2.6.6 (r266:84292, Sep 4 2013, 07:46:00)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)]

Call it with our alias, and notice that Python 2.7 is used:

[smccarty@keith ~]$ python27 script.py
Hello, World! 2.7.5 (default, May 23 2013, 06:08:09)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)]

This answer would be helpful to those who have limited auth access on the server.

I had a similar problem for python3.5 in HostGator's shared hosting. Python3.5 had to be enabled every single damn time after login. Here are my 10 steps for the resolution:

1. Enable the python through scl script python_enable_3.5 or scl enable rh-python35 bash.

2. Verify that it's enabled by executing python3.5 --version. This should give you your python version.

3. Execute which python3.5 to get its path. In my case, it was /opt/rh/rh-python35/root/usr/bin/python3.5. You can use this path to get the version again (just to verify that this path is working for you.)

4. Awesome, now please exit out of the current shell of scl.

5. Now, lets get the version again through this complete python3.5 path /opt/rh/rh-python35/root/usr/bin/python3.5 --version.

   It won't give you the version but an error. In my case, it was

/opt/rh/rh-python35/root/usr/bin/python3.5: error while loading shared libraries: libpython3.5m.so.rh-python35-1.0: cannot open shared object file: No such file or directory

6. As mentioned in Tamas' answer, we gotta find that so file. locate doesn't work in shared hosting and you can't install that too.

   Use the following command to find where that file is located:

find /opt/rh/rh-python35 -name "libpython3.5m.so.rh-python35-1.0"

7. Above command would print the complete path (second line) of the file once located. In my case, output was

find: `/opt/rh/rh-python35/root/root': Permission denied
/opt/rh/rh-python35/root/usr/lib64/libpython3.5m.so.rh-python35-1.0

8. Here is the complete command for the python3.5 to work in such shared hosting which would give the version,

LD_LIBRARY_PATH=/opt/rh/rh-python35/root/usr/lib64 /opt/rh/rh-python35/root/usr/bin/python3.5 --version

9. Finally, for shorthand, append the following alias in your ~/.bashrc

alias python351='LD_LIBRARY_PATH=/opt/rh/rh-python35/root/usr/lib64 /opt/rh/rh-python35/root/usr/bin/python3.5'

10. For verification, reload the .bashrc by source ~/.bashrc and execute python351 --version.

Well, there you go, now whenever you login again, you have got python351 to welcome you.

This is not just limited to python3.5, but can be helpful in case of other scl installed softwares.