We Keep Coding

IPython reloading different module?

I made a test of shadowing Python's built-in string module with my own
module named 'string', to test module search path behavior. My custom
string script has only print('string' * 2) for contents. It is
located in the current directory as shown in code below.
Python 3.6.4 |Anaconda custom (64-bit)| (default, Jan 16 2018, 10:22:32) [MSC v.1900 64 bit (AMD64)]
Type 'copyright', 'credits' or 'license' for more information
IPython 6.2.1 -- An enhanced Interactive Python. Type '?' for help.
In [1]: %pwd
Out[1]: 'C:\\Users\\stephen'
In [2]: import string
In [3]: string
Out[3]: <module 'string' from 'C:\\ProgramData\\Anaconda3\\lib\\string.py'>
In [4]: import imp
In [5]: imp.reload(string)
stringstring
Out[5]: <module 'string' from 'C:\\Users\\stephen\\string.py'>
Three questions about reload in IPython:
Why did reload think the module it actually imported (the local string.py) had already been imported? Is it just the sameness of file
name?
Why did reload import a different module than the one already imported? Did it skip the check of sys.modules dictionary, which was
checked first during original import?
Why did reload/IPython/Python not know it had pulled a fast one here, switching one module for another?
Edit: In going back and forth trying to take care of Stack Overflow complaining about my code block, I inadvertently lost some of what I meant to say. Here is what I can remember:
IPython is adding the built-in string module to sys.modules dictionary at startup (sys.modules is searched before sys.path), something the regular Python interactive prompt doesn't do. So I got a different behavior from the interactive prompt vs. IPython. With the interactive prompt, I always got the local string.py, since sys.path starts with current directory for module search. So, this much I understand about the difference between regular interactive (Anaconda) and IPython. The questions I listed are what remain confusing for me.

reload is supposed to repeat the process of locating the source code for the module it's reloading, and if it finds a different file from what the original import found, it's supposed to use the new file. After all, it needs to handle cases where a module was moved, or where a normal module was changed to a package or an extension module.
reload is not supposed to look at sys.modules and stop if it finds something. If it did that, it would perform no reloading!
The reason reload finds the local string.py file when the initial IPython-internal import didn't is because the import path has changed since the first import. You ran IPython in a way that doesn't cause Python itself to put the working directory on the module search path, and IPython imported the string module from the standard library under that configuration. Afterward, IPython placed the working directory on the module search path itself, mimicking regular interactive Python, so reload found the local string.py.

Tested on my Kernel
Looks you are using a local module name that shadows the name of a standard library or third party package or module that the application relies on. Python imports usually check from the the sys.path setting which might be set under Users\stephen. Hence when we reload it, it picks the first occurrence. Hope it helps.
For reference: https://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html

What is the replacement for python IN package?

I am trying to use a code which was written for python 2 and may run with python 3.6.0, but it does not run with python 3.6.4. It imports the IN module, and uses IN.IP_RECVERR. I tried to google it, but it is a 'bit' hard to find anything about a module called IN (naming fail?). To demonstrate in REPL, that it works in python 2, but not in 3.6.4:
$ python2
Python 2.7.14 (default, Jan 5 2018, 10:41:29)
[GCC 7.2.1 20171224] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import IN
>>> IN.IP_RECVERR
11
>>>
$ python3
Python 3.6.4 (default, Jan 5 2018, 02:35:40)
[GCC 7.2.1 20171224] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import IN
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'IN'
>>>
What is the replacement for this IN module in newer versions of python 3?

This is presumably the private plat-linux/IN.py module, which was never intended to be used. There have been plans to remove these plat-* files for a few zillion years, but it looks like it finally happened in issue 28027 for 3.6. As mentioned in What's New in Python 3.6:
The undocumented IN, CDROM, DLFCN, TYPES, CDIO, and STROPTS modules have been removed. They had been available in the platform specific Lib/plat-*/ directories, but were chronically out of date, inconsistently available across platforms, and unmaintained. The script that created these modules is still available in the source distribution at Tools/scripts/h2py.py.
Most of the useful constants that are at least somewhat portable (as in you can expect them to be available and work the same on your old laptop's linux and your brand-new Galaxy's linux, if not on OS X or Solaris) have long been made available through other places in the stdlib.
I think this specific one you're looking for is an example of not completely useless, but not portable enough to put anywhere safe, because linux documents the existence of IP_RECVERR, but not its value. So, you really need the version from your own system's ip headers.
The way to do this safely, if you actually need the IN module, is to run Tools/scripts/h2py.py with the Python version you're using, on the specific platform you need. That will generate an IN.py from the appropriate headers on your system (or on your cross-compilation target), which you can then use on that system. If you want to distribute your code, you'd probably need to put a step to do that into the setup.py, so it'll be run at install time (and at wheel-building time for people who install pre-built wheels, but you may need to be careful to make sure the targets are specific enough).
If you don't need to be particularly portable, you just need to access the one value in a few scripts that you're only deploying on your laptop or your company's set of identical containers or the like, you may be better off hardcoding the values (with a nice scare comment explaining the details).

Print colorized output - working from console but not from script

I have weird problem that I cannot put my finger on. There is a program that I use (and contribute from time to time) that has colorized console output. Everything worked great until I reinstalled Windows. Now I cannot get colorized output.
This is the script that is used for colorizing.
I have managed to narrow down the problem to, more or less, simple situation, but I have no idea what is wrong.
This is console prompt that works as expected (string test is printed in red):
Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path.insert(0, r'c:\bin\SV\tea\src')
>>> from tea.console.color import cprint, Color
>>> cprint('test\n', Color.red)
test
>>>
But when I run following script with same version of python I get output test but not in red color (there is no color, just default console color):
import sys
sys.path.insert(0, r'c:\bin\SV\tea\src')
from tea.console.color import cprint, Color
cprint('test\n', Color.red)
The same setup worked before I reinstalled my system.
I have checked, environment variables in interactive mode and script are the same.
I have tried this in standard windows command prompt and Console, program that I
usually use.
OS in question is Windows 8 and before reinstall this was also used on Windows 8.
Same code with same setup works at computer at work (Windows 7).
I have Python 2.7 and Python 3.3 installed (as I did before). I have tried to run script
with calling python interpreter directly (c:\Python27\python.exe) or with py -2,
but it does not help.
IPython and mercurial colorizes output as it should.
Any ideas what can I try to make this work?
Edit:
Maybe it was not clear, but script I use to colorize output is given in a link in question. Here it is once again:
https://bitbucket.org/alefnula/tea/src/dc14009a19d66f92463549332a321b29c71d47b8/src/tea/console/color.py?at=default

I have found the problem and solution.
I believe that the problem was the bug in x64 ctypes module. I had Python 2.7 x64 installed and with that version following line (from script that I linked in question):
ctypes.windll.kernel32.SetConsoleTextAttribute(std_out_handle, code)
returns error code 6 with description The handle is invalid. After some investigation, I deduced that problem might be x64 version of python, so I installed 32-bit version and everything works as expected.
Since this solves my problem, and I do not have the time for deeper analysis I will leave it at this, just wanted to give some kind of resolution for question.

module object has no attribute 'Screen'

I am teaching myself python from this site. On Chapter 3, when I typed the code in the given example, I got the following error--
Python 3.2 (r32:88445, Mar 25 2011, 19:28:28)
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import turtle
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "turtle.py", line 2, in <module>
wn = turtle.Screen()
AttributeError: 'module' object has no attribute 'Screen'
>>>
Is this something that I need to download and install? I tried looking into docs.python.org, but my nose started to bleed reading all that tech stuff.
Kindly point me in the right direction please? Thank you.

Adam Bernier's answer is probably correct. It looks like you have a file called turtle.py that Python is picking up before the one that came with your Python installation.
To track down these problems:
% python
Python 2.7.1 (r271:86832, Jan 29 2011, 13:30:16)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
[...] # Your ${PYTHONPATH}
>>> import turtle
>>> turtle.__file__
'/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/turtle.pyc' # Should be under your Python installation.
>>>
If you see something like this:
>>> import turtle
>>> turtle.__file__
'turtle.py'
Then you'll want to move turtle.py (and any corresponding turtle.pyc or turtle.pyo files) in your current working directory out of the way.
As per the comments below, you'll find a wealth of information about a module, including its pathname and contents by calling help() upon it. For example:
>>> import turtle
>>> help(turtle)

Rename turtle.py. It is clashing with the imported module of the same name.
I tested that the code from that site works in Python 2.6 (without installing any external packages).
From http://docs.python.org/tutorial/modules.html#the-module-search-path
When a module named spam is imported, the interpreter searches for a file named spam.py in the current directory, and then in the list of directories specified by the environment variable PYTHONPATH.
So the Python interpreter is finding your turtle.py file, but not seeing a Screen class within that file.
Johnsyweb's answer contains several good tips on how to debug this kind of issue. Perhaps the most direct way of determining where on the filesystem an imported module resides is to use repr(module) or simply type the module name at the REPL prompt, e.g.:
>>> turtle
<module 'turtle' from '/usr/lib/python2.6/lib-tk/turtle.pyc'>

Another problem that people may encounter is due to an installation issue on Linux systems. On my Windows machine, 'turtle' was just there and I was able to import turtle with no problem. When I tried to import turtle in Ubuntu, it didn't find the module, so I tried to install it.
When I did sudo pip install turtle, it installed a package 'turtle' which apparently is very different: "Turtle is an HTTP proxy whose purpose is to throttle connections to specific hostnames ...." This 'turtle' most certainly does not have "Screen" or anything related to a little drawing turtle. So I ended up with the same error as the user in the question of module has no attribute 'Screen'.
For Ubuntu, what I needed to do was:
sudo pip uninstall turtle
sudo apt-get install python-tk
Then when I did import turtle, all of the expected modules were found.

Go to the directory where you save your python files. There is a file named turtle.py. Either remove it, or rename it. This will work.
thanks,

Probably not related, but I spent some time tracking down this same error and found a different cause: I had a file named "copy.py" in the folder with my project.
This "copy.py" was an assignment to make a function that returns a deep copy of a list. The turtle library imports "deepcopy" from "copy"; turns out there's already a "copy.py" as part of python (which I'd never seen/used) & by having a file named "copy.py" in my project folder, it was causing turtle to import the wrong copy.py, which was causing the error to be thrown in turtle (my copy.py assignment's deepcopy function didn't work the same way as the one in python).
This is a more general suggestion, but it's good to double check and make sure you don't have any filenames that are in conflict with actual python imports used in your project. There are too many to list here, but ones used by turtle include: tkinter, types, math, time, inspect, sys, and copy. If you have any of these with a .py in your folder (for example, if you had previously created an inspect.py), turtle will be loading that instead of the built-in library & will not work.

Using pyobjc imports in PyDev in Eclipse on Mac OS X

I've installed and configured PyDev version 1.6.5.2011020317 inside Eclipse, running on Mac OS X 10.6.6:
Version: Helios Service Release 1
Build id: 20100917-0705
I used 'Auto Config' to set up my Python interpreter: it correctly found /usr/bin/python (which is Python version 2.6.1) and added various system folders to the PYTHONPATH, including /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/PyObjC. Now that path is the correct path to the Foundation module in OS X, as evinced by the command-line interpreter:
$ python
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Foundation
>>> Foundation.__path__
['/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/PyObjC/Foundation']
So why does PyDev complain about "Undefined variable from import: NSDictionary" on this class:
import Foundation
class MyClass(object):
def __init__(self, projectPath):
'''
Constructor
'''
self.projectDict = Foundation.NSDictionary.dictionaryWithContentsOfFile_(projectPath)
when I can use that class without any problem from the command-line interpreter?
Update: OK, I found out why it complains, which is that the Foundation module is using ScriptingBridge to dynamically generate the classes - presumably pydev isn't actually importing the module to see what classes are inside, it's just looking for .py[c] files. So let my question not be "why does this happen", but "what do I do to fix it"?

Why does this happen?: PyDev has no support for parsing the PyObjC scripting bridge metadata, and therefore has no way of introspecting / extracting symbols for many of the PyObjC classes.
What to do to fix it: In the PyDev source code there are several Python scripts which handle discovery of this metadata. The scripts are executed by Eclipse using the configured interpreter, and they return strings which are used to configure the interpreter, fill in completion lists, show usage tips, etc.
The scripts which seem relevant to your needs are:
interpreterInfo.py - called to obtain the list of directories and other default top-level imports for a given interpreter.
importsTipper.py - generates usage tips for a given symbol.
pycompletion.py - generates a list of completions for a given symbol.
Examples of calls to the above scripts using the system interpreter:
% /usr/bin/python interpreterInfo.py | grep PyObjC
|/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/PyObjCINS_PATH
Generate completions for a module:
>>> import pycompletion
>>> print pycompletion.GetImports('os')
##COMPLETIONS(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.py,(EX_CANTCREAT, 3),(EX_CONFIG, 3),(EX_DATAERR, 3), ....
It seems possible to create a simple macobjc.py library with routines which detect and read the PyObjC.bridgesupport file(s). The PyDev scripts could be modified to call into this library in order to return the list of valid completions for those classes. You'll need to point Eclipse to a local copy of the PyDev source in order to develop and test your patches against these files. Once you're done you can send it upstream; I have to believe the PyDev folks would accept a well-written patch to support PyObjC completions.