On 03 Oct 2005 00:22:22 -0700, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
>"El Pitonero" <[EMAIL PROTECTED]> writes: >> The thing is, there are two sides to every coin. Features surely can >> be viewed as "goodies", or they can be viewed as "handcuffs". > >Let's see, say I'm a bank manager, and I want to close my cash vault >at 5pm today and set its time lock so it can't be opened until 9am >tomorrow, including by me. Is that "handcuffs"? It's normal >procedure at any bank, for good reason. It's not necessarily some >distrustful policy that the bank CEO set to keep me from robbing the >bank. I might have set the policy myself. Java lets me do something >similar with instance variables. Why is it somehow an advantage for >Python to withhold such a capability? > >> Sure, in these very dynamic languages you can ACCIDENTALLY override >> the default system behavior. How many Python programmers have once >> upon a time done stupid things like: >> list = 3 > >That's just a peculiarity, not any deep aspect of Python. Try it for >'None' instead of 'list': > > >>> None = 3 > SyntaxError: assignment to None > >Why is 'list' somehow different from 'None'? I'd say there's a case >to be made for having the compiler protect 'list' and other builtins >the same way it protects 'None'. Python won't be any less dynamic >because of it. > I think I can write you a custom import that will prevent the assignment of a list of names you specify in the code of the imported module. Would that be useful? Or would it be more useful to put that detection in py/lint/checker/etc (where it probably already is?)? Would you want to outlaw 'None' as an attribute name? Python seems to be straddling the fence at this point: >>> class C(object): pass ... >>> c = C() >>> c.None = 'c.None' SyntaxError: assignment to None >>> vars(c)['None'] = 'c.None' >>> c.None 'c.None' ;-) >> The upside is exactly the same as the fact that you can override the >> "list()" function in Python. Python is dynamic language. > >That's not exactly an upside, and it has nothing to do with Python >being dynamic. C is static but you can override 'printf'. Overriding >'list' in Python is pretty much the same thing. > >> In Python, if you have a private variable: >> >> self._x = 3 >> >> and you, for curiosity reasons and DURING runtime (after the program is >> already up and running) want to know the exact moment the self._x >> variable is accessed (say, print out the local time), or print out the >> calling stack frames, you can do it. And I mean the program is running. > >So let's see: > > def countdown(): > n = 3 > while n > 0: > yield n > g = countdown() > print g.next() # 3 > print g.next() # 2 > >where's the Python feature that lets me modify g's internal value of n >at this point? How is that different from modifying a private >instance variable? "Python feature" means something in the language >definition, not an artifact of some particular implementation. Is >Python somehow deficient because it doesn't give a way to do that? Do >you want to write a PEP to add a way? Do you think anyone will take >it seriously? I could see it as part of a debugging interface that might let you mess more with frames in general. I wouldn't be surprised if a lot of the under-the-hood access we enjoy as it is was a byproduct of scratching debugging-tool-need itches. Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
