Python syntax in Lisp and Scheme

[Pascal Costanza]

Alex Martelli wrote:

> Pascal Costanza wrote:
>    ...
> 
>>>>Does Python allow local function definitions?
> 
>    ...
> 
>>>>Can they shadow predefined functions?
> 
>    ...
> 
>>>Yes, named objects, including functions can (locally) shadow
>>>(override) builtins.  It is considered a bad habit/practice unless
>>>done intentionally with a functional reason.
>>
>>Well, this proves that Python has a language feature that is as
>>dangerous as many people seem to think macros are.
> 
> 
> Indeed, a chorus of "don't do that" is the typical comment each
> and every time a newbie falls into that particular mis-use.  Currently,
> the --shadow option of PyChecker only warns about shadowing of
> _variables_, not shadowing of _functions_, but there's really no
> reason why it shouldn't warn about both.  Logilab's pylint does
> diagnose "redefining built-in" with a warning (I think they mean
> _shadowing_, not actually _redefining_, but this may be an issue
> of preferred usage of terms).
> 
> "Nailing down" built-ins (at first with a built-in warning for overriding 
> them, later in stronger ways -- slowly and gradually, like always, to 
> maintain backwards compatibility and allow slow, gradual migration of the 
> large existing codebase) is under active consideration for the next version 
> of Python, expected (roughly -- no firm plans yet) in early 2005.

OK, I understand that the Python mindset is really _a lot_ different 
than the Lisp mindset in this regard.

> Note that SOME built-ins exist SPECIFICALLY for the purpose of
> letting you override them.  Consider, for example, __import__ -- this
> built-in function just exposes the inner mechanics of the import
> statement (and friends) to let you get modules from some other
> place (e.g., when your program must run off a relational database
> rather than off a filesystem).  In other word, it's a rudimentary hook
> in a "Template Method" design pattern (it's also occasionally handy
> to let you import a module whose name is in a string, without
> going to the bother of an 'exec', so it will surely stay for that purpose
> even though we now have a shiny brand-new architecture for
> import hooks -- but that's another story).

Ah, you want something like final methods in Java, or better probably 
final implicitly as the default and means to make select methods 
non-final, right?

> Anyway, back to your contention: I do not think that the fact that
> the user can, within his functions, choose very debatable names,
> such as those which shadow built-ins, is anywhere as powerful,
> and therefore as dangerous, as macros.  My own functions using
> 'sum' will get the built-in one even if yours do weird things with
> that same name as a local variable of their own.  The downsides
> of shadowing are essentially as follows...

What makes you think that macros have farther reaching effects in this 
regard than functions? If I call a method and pass it a function object, 
I also don't know what the method will do with it.

Overriding methods can also be problematic when they break contracts. 
(Are you also considering to add DBC to Python? I would expect that by 
now given your reply above.)

Can you give an example for the presumably dangerous things macros 
supposedly can do that you have in mind?


Pascal