'p' should be protected, or at least provide a warning

[GoogleCodeExporter]

People find it pretty confusing confusing when defining something p overwrites 
the penguin, especially since reset() didn't redefine it and they wound up just 
having to close out of the session and reopen it.

What version of the product are you using? On what operating system?
0.8 Ubuntu 9.10

Original issue reported on code.google.com by aresnick...@gmail.com on 28 Jun 2010 at 2:36

[GoogleCodeExporter]

There are a lot of names that get pulled in to the interactive namespace 
automatically.

Does overwriting p cause special pain? Or do you think that all of those names 
that are pulled in should be protected (or warned about) somehow?

A couple of workarounds for now:

p = pynguin

or

p = pynguins[0]

Original comment by miss...@hotmail.com on 28 Jun 2010 at 8:02

[GoogleCodeExporter]

p causes special pain just because it meant that the person lost control of the 
pynguin and so ended up restarting their session.  I don't know if there are 
other things like p, but the important piece seem to be that the user doesn't 
know about p ahead of time (e.g. redefining "fd" is likely to be a conscious 
act).  But no, there aren't other examples that come to mind.

Original comment by aresnick...@gmail.com on 28 Jun 2010 at 9:01

[GoogleCodeExporter]

I don't understand how overwriting p could cause loss of control of the pynguin.

Do you have a transcript that shows how that can happen?

Original comment by miss...@hotmail.com on 29 Jun 2010 at 7:57

[GoogleCodeExporter]

Oh, I was mistaken.  You lose control of later penguins that are defined (see 
attached).  It's not obvious to me that that should change, though.

Original comment by aresnick...@gmail.com on 29 Jun 2010 at 9:38

Attachments:

• protecting_pynguins.pyn

[GoogleCodeExporter]

Yeah. I don't think there's any way to protect against that....

People have to learn at some point that if they redefine a variable they are 
going to lose hold of whatever the name was attached to previously.

They can always retrieve a handle through the pynguins list (unless of course 
they write over that also...)

I think it would be a good idea for reset() to try to restore those items that 
get pulled in to the interactive namespace automatically.

Also, if pynguins do get a .name attribute, there could be a way to get a 
pynguin by name.

Original comment by miss...@hotmail.com on 29 Jun 2010 at 10:02

[GoogleCodeExporter]

Full reset -- reset(True) -- now restores the default pynguin builtins.

User re-defining p or pynguin could still cause problems with some of the 
examples, but it should not interfere with user code (unless they are using p 
or pynguin in which case it's their own fault :o)

I'm not too happy with having these global variable hanging around that can 
cause interference in far away parts of the program, but I also don't think the 
best approach is to write protect them...

Maybe just use these kinds of problems as a way to teach about the evils of 
global values?

Original comment by miss...@hotmail.com on 31 Jul 2010 at 4:40

• Changed state: Invalid