We Keep Coding

How to solve ModuleNotFoundError: No module named 'string' error in Python 3?

I was trying to add the Strings library into the Robot Framework Interpreter folder in PyCharm, where first it showed me error
Command errored out with exit status: 1
So, I googled out this issue first, and this link suggested me to delete 'strings.py' file from the libraries. I did so and now nothing is working.
Anything I do now, it shows error of "ModuleNotFoundError: No module named 'string'".
I could not even install string using
pip install strings
command.
Whatever I try to do with pip, now shows this error.
Can anyone please suggest me the solution for this?
I am using Python version 3.10.

Several notes:
The library in question is 9 years old, is not maintained, is known by the author to be buggy, was written as a joke, and does not contain anything useful. There is no good reason why you should be trying to install it for your project. If you think you need it for something, then you have some other misconception that needs to be cleared up.
The link you found did not tell you to delete strings.py from "the libraries". It said something about deleting string.py - notice, no s at the end - from a local project folder. The reason for this is because that name conflicts with the library name. The page author's own source file, named string.py, sought to import the standard library file string.py (as it clearly says import string in the screen shot), but it cannot - because it finds itself first. This is a common problem for new Python users.
DO NOT EVER MANUALLY EDIT THE CONTENTS OF YOUR INSTALLATION DIRECTORY ON THE ADVICE OF SOME RANDOM WEB PAGE.
Ideally, don't ever do it at all. That content is not intended to be touched. Installers exist for a reason. If for some incredibly specific reason you feel the need to do this, make sure you have backups of everything and that you are 100% sure you can restore everything to its initial state if anything goes wrong.
The person writing that web page was incorrect. The installation error had nothing to do with the string.py file.
The actual cause of the problem is that the package is broken and cannot be installed properly on anyone else's machine. Again, this is no big loss as there is no use for the package anyway.
The reason it is broken is that the setup script for the package tries to import the code that's being installed, in order to get version and author information. This seems to work locally, but fails for everyone else.
To reiterate: the person writing that article wrote nonsense. (I'm not surprised; the page formatting is awful and the grammar isn't particularly great either.) Looking further, it appears that the entire website is authored by the one person, who is clearly just trying to self-promote (with a Youtube channel as well) while lacking the necessary expertise. Browsing around the rest of the site a bit, I see articles that are pedantic and not very insightful, and occasionally inaccurate - but all very SEO optimized.
I recommend ignoring that website entirely.
To reiterate: the string module comes with your Python. You cannot reinstall it with pip - not with the strings package you found, nor any other package. Your options are:
Find the correct string.py contents (possibly from a backup, assuming you thought to make a backup before deleting something from an installation directory) and restore them. This is the official repository for the reference implementation of Python. You might be able to find it in there somewhere. I don't recommend trying. There is a lot to go through and it is possible to damage things further.
Reinstall Python completely.

The error that you are getting is because you deleted the string.py file. There is no string module to be imported from PyPi. This is why pip install string doesn't work. Restore the deleted file as it is not the cause of your problem.
If you try to install Strings library it will fail because you are using Python 3.10 and the Strings library that you want to import and install is quite old and not supported for this Python version. Therefore you get the ModuleNotFoundError: No module named 'strings' that you see in the link that you attached.
For the setup.py file from the library I see that it recommends using Python 3.3, so I will recommend you to use that version of Python if you want to use this specific library.
Please note that the link that you provided is probably in case that you have created your own string.py file.

I solved this question by deleting any __pycache__ folder in the project directory.

libselinux-python bindings and ansible

Sorry for answering my own question, but I've seen this crop up in multiple forums, so I wanted to post this in hope it helps someone else.
The basic problem occurs when trying to run Ansible against older Python interpreters -- particularly Python 2.6 on RedHat 5 -- and getting error messages about 'libselinux bindings not available' or similar errors.
While this could happen for any Python-based application, I see it most commonly on Ansible. Ansible presumes the selinux module is available and will always attempt to import it at runtime.

The libselinux-python bindings are not a simple python module. The module must be cross-compiled against both the target version of Python and the target version of libselinux. The nice folks maintaining the RedHat 5 EPEL repositories did not generate a Python 2.6/libselinux 1.33 module.
The 'existing' libselinux-python module from the standard repos will not work, because it is specific to the supplied Python 2.4 interpreter. If you copied the module from a different Python 2.6 install -- say, a RedHat 6 system -- that won't work either, because it's built against the wrong version of libselinux. While you can amuse yourself with the various errors created by different combinations, Ansible won't bother to distinguish between them; it will just state that the bindings are unavailable.
The solution is to create a 'stub' selinux python module to pacify Ansible. Create a file
/usr/lib64/python2.6/site-packages/selinux/__init__.py
with the following contents:
def is_selinux_enabled():
return False
def is_selinux_mls_enabled():
return False
(This is Python code, so mind the indents.) This effectively disables Ansible from working with selinux. Also, tasks running against these systems should not include any selinux attributes, such as setype or seuser. (Honestly, I haven't tested it fully.) But basic modules like lineinfile or command now work properly.
This does not required disabling selinux; it only prevents Ansible from manipulating selinux attributes. If necessary, you can always use the one of the command modules to script around it.

I would have liked to post this as a comment to the #crankyeldergod's answer (as his response lead me to figure out my fix to this issues) but I don't have enough posts to comment yet.
I also kept receiving the "Aborting, target uses selinux but python bindings (libselinux-python) aren't installed!" error despite having the libselinux-python packages installed. I went into /usr/lib64 and checked the python directories I found there until I located the one with selinux files present. I made note of that version of python and declared it explicitly in my inventory file, ie - ansible_python_interpreter=/usr/bin/python3.6 in my case and that resolved the issue.

Case sensitivity with names of modules and files in python 2.7.15

I have encountered a rather funny situation: I work in a big scientific collaboration whose major software package is based on C++ and python (2.7.15 still). This collaboration also has multiple servers (SL6) to run the framework on. Since I joined the collaboration recently, I received instructions on how to set up the software and run it. All works perfectly on the server. Now, there are reasons not to connect to the server to do simple tasks or code development, instead it is preferrable to do these kind of things on your local laptop. Thus, I set up a virtual machine (docker) according to a recipe I received, installed a couple of things (fuse, cvmfs, docker images, etc.) and in this way managed to connect my MacBook (OSX 10.14.2) to the server where some of the libraries need to be sourced in order for the software to be compiled and run. And after 2h it does compile! So far so good..
Now comes the fun part: you run the software by executing a specific python script which is fed as argument another python script. Not funny yet. But somewhere in this big list of python scripts sourcing one another, there is a very simple task:
import logging
variable = logging.DEBUG
This is written inside a script that is called Logging.py. So the script and library only are different by the first letter: l or L. On the server, this runs perfectly smooth. On my local VM set up, I get the error
AttributeError: 'module' object has no attribute 'DEBUG'
I checked the python versions (which python) and the location of the logging library (print logging.__file__), and in both set ups I get the same result for both commands. So the same python version is run, and the same logging library is sourced but in one case there is a mix up with the name of the file that sources the library.
So I am wondering, if there is some "convention file" (like a .vimrc for vi) sourced somewhere where this issue could be resolved by setting some tolerance parameter to some other value...?
Thanks a lot for the help!
conni

as others have said, OSX treats names as case-insensitive by default, so the Python bundled logging module will be confused with your Logging.py file. I'd suggest the better fix would be to get the Logging.py file renamed, as this would improve compatibility of the code base. otherwise, you could create a "Case-sensitive" APFS file system using "Disk Utility"
if you go with creating a file system, I'd suggest not changing the root/system partition to case-sensitive as this will break various programs in subtle ways. you could either repartition your disk and create a case-sensitive filesystem, or create an "Image" (this might be slower, not sure how much) and work in there. Just make sure you pick the "APFS (Case-sensitive)" format when creating the filesystem!

What versions of Python will work in Windows XP?

I would like the most advanced version of Python that still works on Windows XP. I need both Python 2 and Python 3.
What versions of Python will work on Windows XP?

I found that Python 2.7.9 and Python 3.4.4 are the newest versions of Python that work in Windows XP. I found this out through trial and error.

I've found a desperate guy (Daniel Pistelli) who didn't give up at the windows error dialog:
https://ntcore.com/?p=458
I like how he approaches the topic:
If we try to start any new application on XP, we’ll get an error
message informing us that it is not a valid Win32 application. This
happens because of some fields in the Optional Header of the Portable
Executable.
[...]
Fortunately, it’s enough to adjust the fields in the executable we want to start (python.exe), there’s no need to adjust the DLLs as well. If we try run the application now, we’ll get an error message due to a missing API in kernel32. So let’s turn our attention to the imports.
And then he goes on for another 5-6 screens. To sum it up, apparently you'll have to:
Modify the python.exe header,
Run a tiny Python script to remap some DLL calls,
Recalculate some binary hashes,
Create a fake kernel32.dll with certain calls forwarded,
Modify python37.dll to point to this fake thing,
and then you're all set. To be honest I couldn't quite follow (let alone verify!) some of the steps but it looks legit and there are links with Daniel's half-baked solutions for the harder parts, also a lot of Python sources explained. I will definitely give this thing a try.
In fact, here are the final scripts from his GitHub page:
https://github.com/dpistelli/xptmrt
Moral of the story: you can be crazy, but you'll never be dismantle-all-dlls-and-exes-and-open-hexeditors-and-disassemble-hashing-algorithms-and-mock-it-all-together-so-it-works-under-xp-crazy!

Someone had built Python 3.4.10, which is slightly newer than the officially prescribed Python3 v3.4.3/3.4.4 for Windows XP. Since it comes from the third-party (not the official Python website), use at your own risk,
-->Download<--

i tried 3.3.3 but i came up with an error message use 3.4.3/2.7.9 they are the only versions that work now sadly

There are several custom builds of Python >3.44 suitable for Windows XP. A poster at reddit has provided Python 3.55 here:
https://www.reddit.com/r/Python/comments/3tgi0t/python_35_x86_on_windows_xp/
Here is an XP compatible build of 3.6.15 source code only:
https://alex-free.github.io/winxp_python3.6.15/
At the MSFN forums someone has provided an XP compatible build of 3.8.1350 here:
https://msfn.org/board/topic/183741-python-3813-for-windows-xp-sp3/

Official website says about 3.4.10: https://www.python.org/downloads/release/python-3410/

Any of them, python is very platform independent. Some features might not work, but that would best be found in the documentation.

Python Django httpd - [notice] child pid XXXXX exit signal Segmentation fault (11)

Sometimes it responds like a charm, but sometimes I got the error "No data received". I searched around but nothing worked. The posts which are suggesting the use of "gdb" to debug the apache for possible errors, well, I do not have the chance to test it with gdb, because in the server I'm working on, there's not any development softwares or libraries (except python), and I cannot install them. And the other half of the posts suggest the solutions which are compatible with webservers working with PHP - I don't know whether it makes any difference to the problem or not.
My httpd configuration is like this:
Apache/2.2.11 (Unix) DAV/2
mod_ssl/2.2.11 OpenSSL/0.9.8b
mod_jk/1.2.15
PHP/5.1.6
mod_wsgi/2.1-BRANCH
Python/2.4.3 configured
I use Django, and hence mod_wsgi. Is there any other way for debugging this issue rather than using gdb?
Note that, in the previous versions of my application, I didn't get any error like this, never. For the newer versions, I didn't change the technology, just upgraded Django to 1.3, started using ZSI 2.1 on CentOS5.
Thanks in advance.

As Graham-Dumpleton commented above, it seems to be a well known issue in mod_wsgi, namely with the expat library version compatibility.
The reason for the failure (as well as the steps to solve it) are described here
tl;dr solution (from the link above):
Note that this only applies to Python versions prior to Python 2.5.
From Python 2.5 onwards, the copy of the "expat" library bundled in
with Python is name space prefixed, thereby avoid name clashes with an
"expat" library which has previously been loaded.