vasvir at iit.demokritos.gr
Mon Feb 26 06:50:35 CET 2001
Tim Peters wrote:
> The language doesn't guarantee this will always work, so it's certainly
Oups! That's the killer argument here.
> Looking up builtins is slower than looking up module globals (a module's
> global dict is always searched before the builtin dict).
> The language may someday make "GlobalVariable" the name of its own builtin,
> and then your code won't work correctly if you either try to use the new
> builtin or call any other module that does (incl. without limitation std
> library modules).
This I don't get it. Why is that? GlobalVariable is just a name to
indicate the purpose of my variable. If a newer version of python use it
in a later stage as a reversed word (__builtins__ variable or function),
then obviously my old program won't be able to use the new functionality
but it will overwrite it happily. So it would work even then.
Consider the following imaginary example. In a project where there is no
need to open files one replaces the open function. So this project will
never manage to open a file but aside from that it will continue to work
> People other than you will be unable to understand your code regardless,
> because GlobalVariable will look to them like an unbound variable (i.e.,
> nobody else uses this trick, so nobody else will recognize the usage
> Introspective tools won't think to look in the builtins either (again
> because nobody else etc).
Valid points too.
Thank you and everybody else for your answers. I think I will try to
avoid that trick anyway.
More information about the Python-list