Logged In: YES 
user_id=971153

> 1. Could you give some code examples for that?

Do you mean examples of intentional interference with
debugger? Well, you could just traverse the stack and check
whether the program runs under debugger and then do anything
you want... But why do you think intentional interference
would ever be an issue? After all python is not a language
to write debugger-resistant applications ;-) 

Anyway, here are some examples of unintentional interference:

1. If you need a custom version of std module, you can
modify sys.path and then import the module.. Which works by
itself. But if pdb is loaded first and imports the module,
then it does not work...

2. Similar problem with any application which changes
sys.stdout/sys.stdin (there is actually a SF bug for that)

3.  Also I don't see how pdb in its current form can control
any program which needs a full-screen control of the terminal...

4. Any program which tries to do any magic with stack and
assumes that top level stack frame is the main application
will not work under pdb (where top level stack frame is pdb)

---------------------------------------------------
And there is a whole separate bunch of intereference issues
when pdb restarts the program.

---------------------------------------------------

When a program does run in pdb's namespace (as would be the
case if this patch is applied), pdb could save copies of all
module global symbols which it needs and thus become immune
to the accidental overwriting of those symbols in the main
program...

There could be a better way...