looking fo documentation for module files

[snippsat]

This is also the greatest flaw of PYTHONPATH. Using the same installed modules for several versions of Python leads to troubles and inconsistencies.

Yes i do agree,i am very aware of what problem's it can cause,so for me personally it's not a problem.
So i would not advice using PYTHONPATH, use site module,and that has been my answer when this topic has been up before.

[Skaperen]

i should use a different directory for my modules for specific to each version of Python? if that is true, then shouldn't i find distributed code written in Python (not coming from the distro maker that is also providing a specific version of Python) in specific packages for specific versions, unless they make a single code base for their entire range of supported Python versions? i generally target 3.5 and up, with my public code. i now have only 3.8 to test with. i forget which version(s) i can get at AWS when i make a cloud instance.

[Skaperen]

So i would not advice using PYTHONPATH, use site module,and that has been my answer when this topic has been up before.

that document says:

This module is automatically imported during initialization. The automatic import can be suppressed using the interpreter’s -S option.

Importing this module will append site-specific paths to the module search path and add a few builtins, unless -S was used. In that case, this module can be safely imported with no automatic modifications to the module search path or additions to the builtins. To explicitly trigger the usual site-specific additions, call the site.main() function.

this is unclear. at first it says it is automatic. then it says what to call. is coding such a call going to suppress the automatic import?

then it says:

Changed in version 3.5: Support for the “site-python” directory has been removed.

now what to do? this is a long and complex setup. can someone who has done this just list the total changes they made (what went where)?

also:

is there an explanation of how things get run when doing a command with the -m option? are arguments in sys.argv as is done for normal commands? is there an advantage to making a command/script be run this way?

i just want to have a place to put modules in that may be for user coded scripts run from their home directories or scripts i add to /usr/local/bin as executables (that and /usr/host/bin), my place to put commands in (which may be bash scripts or binary (ELF) format files)).

why not a /usr/site directory?

[Gribouillis]

this is unclear. at first it says it is automatic. then it says what to call. is coding such a call going to suppress the automatic import?

I think it is very clear:

• If the python executable is invoked without the -S command line switch, the site module is automatically imported and site-specific paths are appended to the module search path.
  
• If python -S is invoked, this doesn't happen, but your code can use import site, and the site-specific paths are appended only if you code calls site.main().
  

Changed in version 3.5: Support for the “site-python” directory has been removed.

In the past, there was a directory lib/site-python on Unix and Mac. This directory no longer exists.

is there an explanation of how things get run when doing a command with the -m option? are arguments in sys.argv as is done for normal commands? is there an advantage to making a command/script be run this way?

The advantage is that a python library can be used as a python program. You don't need to write a module plus an executable script. For the effect of the -m switch on sys.argv, here is the doc.

i just want to have a place to put modules in that may be for user coded scripts run from their home directories

I suggest $HOME/.local/bin

[snippsat]

why not a /usr/site directory?

You can use what folder you want,look at Gribouillis answer in post #6 or my post here.
If i do quick run on older Kali Linux that i where i use default Python and pyenv.

# make folder that want to use 
root@kali-tom:~$ mkdir /home/our_modules

# make a <sitecustomize.py> in our Python version
root@kali-tom:/usr/lib/python3.7$ vim sitecustomize.py

# Add in sitecustomize.py
import site

site.addsitedir('/home/our_modules')

# Test that it work
root@kali-tom:~# python3
Python 3.7.5 (default, Oct 27 2019, 15:43:29) 
[GCC 9.2.1 20191022] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> 
>>> sys.path
[ '/usr/lib/python3.7', '/usr/lib/python3.7/lib-dynload', '/usr/local/lib/python3.7/dist-packages',
'/usr/lib/python3/dist-packages', '/home/our_modules']
>>> exit()

i generally target 3.5 and up, with my public code.

Python 3.5 can say is dead💀 as many modules/libraries dos not support for it anymore.
A core module for many other that many has dependencies of is Numpy.

The Python versions supported by this release 3.8-3.10. Python 3.11 will be supported when it reaches the rc stage.

[Skaperen]

I suggest $HOME/.local/bin

if i have 56 users that means i need to make 56 duplicate copies of the file. i need one single system-wide directory to operate much like /usr/local/bin operates for binary commands (and scripts beginning with '#!').

[Skaperen]

how can i put the local path in the front of sys.path?

Python 3.5 can say is dead💀 as many modules/libraries dos not support for it anymore.

isn't it supposed to be that code written for Python 3.X should work in Python 3.Y where X < Y ? could my code written for Python 3.6 fail in Python 3.8 or Python 3.10 or even Python 3.11 ? i thought such failures were to be limited to major version changes, e.g. code for Python 2.7 could fail in Python 3.X for each X.

[Gribouillis]

f i have 56 users that means i need to make 56 duplicate copies of the file. i need one single system-wide directory to operate much like /usr/local/bin operates for binary commands (and scripts beginning with '#!').

I don't understand why you don't find a directory in our previous answers? What is the result of site.getsitepackages() in your system?

[snippsat]

isn't it supposed to be that code written for Python 3.X should work in Python 3.Y where X < Y ? could my code written for Python 3.6 fail in Python 3.8 or Python 3.10 or even Python 3.11 ? i thought such failures were to be limited to major version changes, e.g. code for Python 2.7 could fail in Python 3.X for each X

You misunderstand this code written in Python 3.6 will not fail in any newer version.
Only if use new features in newer version eg if use the walrus operator🐳 := new in Python 3.8.
Then code will not not work in Python less than Python 3.8.

a = 20
if (b := a) > 10:
    print(f"The value of b is {b} and is greater than 10.") 

Output:
The value of b is 20 and is greater than 10.

NumPy has millions of users and they do of course think of backward compatibility,but also has community policy standard for moving forward.
NEP 29 — Recommend Python and NumPy version support as a community policy standard

When a project releases a new major or minor version,
we recommend that they support at least all minor versions of Python introduced and released in the prior 42 months
from the anticipated release date with a minimum of 2 minor versions of Python,
and all minor versions of NumPy released in the prior 24 months from the anticipated release date with a minimum of 3 minor versions of NumPy.

[Skaperen]

the principle as i understand it is that minor version increments can add new things and using these new things in older (lower) minor versions is not expected to work correctly and is expected to work correctly in future (higher) versions. if Python has adopted this principle under terms of a limited time frame then that's OK. i assume that also means that beyond the time frame in the future, the new feature can be withdrawn.

a link not for Numpy but just for Python would be better. i not limiting what i do to just things that use Numpy.