471,342 Members | 1,941 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,342 software developers and data experts.

reassign to builtin possible !?

Hi there,

I am reading Learning Python 3e from Mark Lutz and just found out that
reassigning to builtins is possible.
What is the reason, why Python allows this ? IMO this is very risky
and can lead to hard to find errors.
(see also Learning Python 3e, Chapter 16, Page 315)
>>True
True
>>False
False
>>True = 1
True
1
>>True = 0
True
0

TIA,
Berni
Jan 3 '08 #1
8 1177
Bernhard Merkle wrote:
Hi there,

I am reading Learning Python 3e from Mark Lutz and just found out that
reassigning to builtins is possible.
What is the reason, why Python allows this ? IMO this is very risky
and can lead to hard to find errors.
(see also Learning Python 3e, Chapter 16, Page 315)
>>>True
True
>>>False
False
>>>True = 1
True
1
>>>True = 0
True
0
This hal always been possible. But it's not reassigning, it's shadowing -
which is a totally different beast. Shadowing builtins is bad style, but
lokal to your context. Which can get nasty of course, if you do the above
on e.g. module level.

But you can't alter the values for True/False globally with this.

Diez
Jan 3 '08 #2
On Jan 3, 2:07 pm, "Diez B. Roggisch" <de...@nospam.web.dewrote:
This hal always been possible. But it's not reassigning, it's shadowing -
which is a totally different beast. Shadowing builtins is bad style, but
lokal to your context. Which can get nasty of course, if you do the above
on e.g. module level.

But you can't alter the values for True/False globally with this.
Are you sure ? what about the following example ?
Is this also shadowing ?

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>import __builtin__
__builtin__.True = False
__builtin__.True
False
>>True
False

Berni
Jan 3 '08 #3
Bernhard Merkle wrote:
On Jan 3, 2:07 pm, "Diez B. Roggisch" <de...@nospam.web.dewrote:
>This hal always been possible. But it's not reassigning, it's shadowing -
which is a totally different beast. Shadowing builtins is bad style, but
lokal to your context. Which can get nasty of course, if you do the above
on e.g. module level.

But you can't alter the values for True/False globally with this.

Are you sure ? what about the following example ?
Is this also shadowing ?

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>import __builtin__
__builtin__.True = False
__builtin__.True
False
>>>True
False
I'm not entirely sure what happens there, but that seems to only work in the
interactive prompt.

--------- test.py ------------
print True

if __builtins__.True == 10:
print "I'm reassigned globally"
--------- test.py -------------

Then, in the interpreter do:

droggisch@ganesha:/tmp$ python
Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Welcome to rlcompleter2 0.96
for nice experiences hit <tabmultiple times
>>__builtins__.True = 10
import test
10
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "test.py", line 5, in <module>
if __builtins__.True == 10:
AttributeError: 'dict' object has no attribute 'True'
>>>

Diez
Jan 3 '08 #4
-On [20080103 14:47], Bernhard Merkle (be*************@googlemail.com) wrote:
>Are you sure ? what about the following example ?
Is this also shadowing ?
It is, as it is local to your current executing interpreter. Any other Python
process that is currently running is unaffected by your shadowing. So as Diez
says, you are not tampering with it on a persistent global level.

--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org/ asmodai
イェルーン ラウフ*ック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/
Any fool can make a rule. And every fool will mind it...
Jan 3 '08 #5
>But you can't alter the values for True/False globally with this.
>
Are you sure ? what about the following example ?
Is this also shadowing ?
>>>import __builtin__
__builtin__.True = False
__builtin__.True
False
It doesn't seem to screw things up globally
>>import __builtin__
t = __builtin__.True
__builtin__.True = False
__builtin__.False = t
True
False
>>False
True
>>1 == 1
True
>>import os
os.path.isdir('.')
True
>>#if they were globally redefined, this would be False
#you'd have to actually reference __builtin__.True
My thought would be if you do something as daft as
redefining/shadowing True and False, you get the headaches that
ensue. Fortunately, since Python is explicit, you can trace back
through the code and see where the inanity occurred.
Additionally, any scoping rules mean that programmer stupidity
can't leak too badly outside the scope of the block containing
the stupidity.

It's the old "DIHWIDT! WDDT!" ("Doctor, it hurts when I do
this!", "well don't do that!") syndrome.

-tkc


Jan 3 '08 #6
On Jan 3, 7:04 am, Bernhard Merkle <bernhard.mer...@googlemail.com>
wrote:
Hi there,

I am reading Learning Python 3e from Mark Lutz and just found out that
reassigning to builtins is possible.
What is the reason, why Python allows this ? IMO this is very risky
and can lead to hard to find errors.
I don't think it's a huge issue. In fact, I think it's a feature. For
example, it'd be extremely issue to reassign open, if you wanted to
implement a virtual file system, and you couldn't modify the module
the used open.
(see also Learning Python 3e, Chapter 16, Page 315)
>True
True
>False
False
>True = 1
True
1
>True = 0
True

0

TIA,
Berni
Jan 3 '08 #7
On Jan 3, 2008 8:05 AM, Tim Chase <py*********@tim.thechases.comwrote:
But you can't alter the values for True/False globally with this.
Are you sure ? what about the following example ?
Is this also shadowing ?
>>import __builtin__
__builtin__.True = False
__builtin__.True
False

It doesn't seem to screw things up globally
>>import __builtin__
>>t = __builtin__.True
>>__builtin__.True = False
>>__builtin__.False = t
>>True
False
>>False
True
>>1 == 1
True
>>import os
>>os.path.isdir('.')
True
>>#if they were globally redefined, this would be False
>>#you'd have to actually reference __builtin__.True

My thought would be if you do something as daft as
redefining/shadowing True and False, you get the headaches that
ensue. Fortunately, since Python is explicit, you can trace back
through the code and see where the inanity occurred.
Additionally, any scoping rules mean that programmer stupidity
can't leak too badly outside the scope of the block containing
the stupidity.

It's the old "DIHWIDT! WDDT!" ("Doctor, it hurts when I do
this!", "well don't do that!") syndrome.
In Py3k this will be a syntax error, like assigning to None is now.
Possibly also in 2.6.
Jan 3 '08 #8
On Jan 3, 8:06 pm, "Chris Mellon" <arka...@gmail.comwrote:
In Py3k this will be a syntax error, like assigning to None is now.
Possibly also in 2.6.
thanks. I feed much better with that :-)
Jan 4 '08 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Jean-S?bastien Bolduc | last post: by
reply views Thread by Joachim Dahl | last post: by
1 post views Thread by Stephen Ferg | last post: by
10 posts views Thread by Shayne Wissler | last post: by
7 posts views Thread by Shailesh Humbad | last post: by
6 posts views Thread by Anders K. Olsen | last post: by
20 posts views Thread by Ari Krupnik | last post: by
3 posts views Thread by Schwammkopf | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.