Ex 46 LPTHW Running Scripts

I have followed the book to a ‘T’ so far, the only difference being I am running Python 3.6.4 which hasn’t made a difference as yet. Am just getting my head around object speak etc, and I have come to

‘A Project Skeleton’ and am following the bouncing ball for WIndows 10.

Everything installs fine except when I come to ‘Activating’ it. It says ‘Running Scripts is disabled’. How do I enable it???

..venvs\lpthw\scripts\activate : File C:\users\james.venvs\lpthw\scripts\activate.ps1 cannot be loaded because
running scripts is disabled on this system. For more information, see about_Execution_Policies at
At line:1 char:1

  • ..venvs\lpthw\scripts\activate
  •   + CategoryInfo          : SecurityError: (:) [], PSSecurityException
      + FullyQualifiedErrorId : UnauthorizedAccess

Answered my own question.

For anyone running Win10, the security is there to stop malicious scripts running without prior approval. Basically you have to change your execution policy to unrestricted on local machine. Well it worked for me.


1 Like

Oh yeah…I think they added that recently but I didn’t have that problem because I installed before that, or I just fixed it and moved on.

However, this brings up a very good security thing that even Microsoft doesn’t get. They can do all they want to disable scripts and stop things running and yet everyone on Windows runs constantly as Administrator. As long as the current active user has total and complete control over the computer there will always be an easy way to hack your machine.

What I do (and you’ll see me do this in a lot of setup videos now) is I create an administrator user and then a non-admin user that I do all my real work in. I never log into the administrator user but instead any time admin rights are needed, windows will prompt me for that user’s password before continuing. Works about 99.9% of the time and only I’ve had a rare problem with some broken installers. Once you do this a huge number of active attacks against windows go away as they almost all rely on the user running as Administrator.

Here’s one study that confirms this:

But it’s kind of just common sense. Remove administrator rights and you remove a lot of the attack surface.


I am running Windows 10 as I said earlier, but I am considering firing up a virtual machine or something using Linux.

I have followed the bouncing ball, and triple checked it and have come up with the following error when I run ‘nosetests’. I even tried the 'python -m nose with the same error.

I have no idea.

(lpthw) PS C:\users\james\projects\skeleton> nosetests

ERROR: Failure: ModuleNotFoundError (No module named ‘name’)

Traceback (most recent call last):
File “c:\users\james\appdata\local\programs\python\python36-32\lib\site-packages\nose\failure.py”, line 39, in runTest
raise self.exc_val.with_traceback(self.tb)
File “c:\users\james\appdata\local\programs\python\python36-32\lib\site-packages\nose\loader.py”, line 418, in loadTestsFromName
addr.filename, addr.module)
File “c:\users\james\appdata\local\programs\python\python36-32\lib\site-packages\nose\importer.py”, line 47, in importFromPath
return self.importFromDir(dir_path, fqname)
File “c:\users\james\appdata\local\programs\python\python36-32\lib\site-packages\nose\importer.py”, line 94, in importFromDir
mod = load_module(part_fqname, fh, filename, desc)
File “c:\users\james\appdata\local\programs\python\python36-32\lib\imp.py”, line 235, in load_module
return load_source(name, filename, file)
File “c:\users\james\appdata\local\programs\python\python36-32\lib\imp.py”, line 172, in load_source
module = _load(spec)
File “”, line 684, in _load
File “”, line 665, in _load_unlocked
File “”, line 678, in exec_module
File “”, line 219, in _call_with_frames_removed
File “C:\users\james\projects\skeleton\tests\NAME_tests.py”, line 2, in
import name
ModuleNotFoundError: No module named ‘name’

Ran 1 test in 0.023s

FAILED (errors=1)

Directory: C:\users\james\projects\skeleton

Mode LastWriteTime Length Name

d----- 16/05/2018 11:12 bin
d----- 16/05/2018 11:13 docs
d----- 18/05/2018 06:31 NAME
d----- 18/05/2018 06:31 tests
-a---- 17/05/2018 07:36 457 setup.py

Directory: C:\users\james\projects\skeleton\name

Mode LastWriteTime Length Name

d----- 18/05/2018 06:31 pycache
-a---- 16/05/2018 11:15 0 init.py

Most likely this has to do with the directory being named NAME and windows being case-insensitive? Basically I think you should rename that directory to name, then in the test import name instead of NAME. Try that.

Thanks a million Zed, funny how naming conventions can give you all sorts of errors. You would think it would give you an error when you made the directory in the first place.

At least it worked and I can continue

That’s the problem with those filesystems that aren’t case sensitive. It’d be fine if they threw up an error on this situations, but the nature of them prevents that.

I am getting an error:

ModuleNotFoundError: No module named ‘nose.tool’

Hey mate, go back in and change some name conventions, i.e. everything with ‘Name’ or NAME’ and change it to name, all lowercase. Make sure you go back into the test folder and change your file to

name_tests.cpython.36.pyc and also ensure that the file match.

from nose.tools import *
import name

def setup():

def teardown():
print(“Tear Down”)

def test_basic():
print(“I ran!”, end=’’)

Notice how your folder is ‘Name’ and your program says ‘name’

Hope I got it right.


Easy @businesscoach : You spelled it:


But it should be:


1 Like

Thank You! I now have the ability to move forward. Yay!

But, It seems from my observation – it only gives the error when the directory was [NAME] and not [name].
It allows it to compile for script names like NAME_tests.py.

But I believe we should keep it consistent for naming convention sake, right? Even though it compiles without an error for capitalized script names.

You have to change every place you use NAME to name, if you want to do that. Honestly, I wish Python would just be a little smarter on this.

1 Like