Guido van Rossum wrote:
> So we have what seems to be an impasse. Some people would really like
> once-expressions to be captured at def-time rather than at the first
> execution per def; this is the only way to use it so solve the "outer
> loop variable reference" problem. Others would really hate it if a
> once could be hidden in unreachable code but still execute, possibly
> with a side effect.
>
> I'm not sure that the possibility of writing obfuscated code should
> kill a useful feature. What do others think? It's basically impossible
> to prevent obfuscated code and we've had this argument before:
> preventing bad code is not the goal of the language; encouraging good
> code is.
I'm coming around to liking the idea of Fredrik's static expressions. def-time
really is a clean way to define when something happens, it provides a nice
readable solution to the early-vs-late binding question, and the only ways
I've managed to break it are by deliberately writing code that's altogether
too clever for its own good.
It should be possible to find some reasonable way to handle module level code,
and pychecker and the like can warn about static expressions in unreachable
code.
I even worked out how to rewrite my
side-effect-free-but-still-too-clever-for-its-own-good example so it worked
under Option 3:
def outer(cases=None):
if cases is None:
# Use unmatchable cases
cases = [() for x in range(3)]
def inner(option, force_default=False):
if not force_default:
switch option:
case in cases[0]:
# case 0 handling
case in cases[1]:
# case 1 handling
case in cases[2]:
# case 2 handling
# Default handling
return inner
I'm happy I've made the best case I can for Option 2, and it's left even me
thinking that Option 3 is a cleaner, more useful way to go :)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
