> sys.__interactivehook__ has the benefit of being cleanly settable from python code.
> But it might well be a YAGNI idea.
I’ll ask python-dev about that.  For the moment, I prefer the idea of a new sys.interactive attribute (boolean).

>> $PYTHONSTARTUP doesn't work with -i
> Perhaps it should?
-i means two things: interactive and inspect.  The second meaning is used when you want python to execute a script or module just as usual but without exiting afterward, to let you inspect the state of the program.  Supporting PYTHONSTARTUP would change these use cases and be an unacceptable change.

 
>> BTW, drawback of doing any such setup in site.py: "python -S" 
>> would be unfriendly!
> People using -S don’t want the customizations done in site, so I 
> don’t think there’s a problem here.

> python -S doesn't disable readline.
> What makes completions more of a "customization" than editing?
> The fact that it'd be implemented in site.py?
If you go back to the first messages of this report, you’ll see that I wasn’t sure what a good location would be, and decided site because it did not look out of place.  There isn’t a stronger rationale than that.  One could argue that even now, site mixes disparate functionality: one program could wish to use -S to disable sys.path munging but run into bugs because the builtin exit is not defined anymore for example.

> Yes, obviously, if it's implemented in site.py, -S should disable it.
We agree.

> My point was that it doesn't have to be implemented there.
I really want to explore all options before renouncing to implement it in site.  I’d like the implementation to be maintainable and shareable with other Python VMs.