«

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

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

On Jan 3, 2:07 pm, "Diez B. Roggisch" <de...@nospam.web.de> wrote:
> 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

Bernhard Merkle wrote:

> On Jan 3, 2:07 pm, "Diez B. Roggisch" <de...@nospam.web.de> wrote:
>> 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 <tab> multiple 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

-On [20080103 14:47], Bernhard Merkle () 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...

>> 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

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

On Jan 3, 2008 8:05 AM, Tim Chase <> wrote:
> >> 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.

On Jan 3, 8:06 pm, "Chris Mellon" <arka...@gmail.com> wrote:
> 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