[ Reinhold Birkenfeld ]:
> Well, with it you could create suites with _any_ introducing
> identifier. Consider:
>
> with:
> (...)
>
> synchronized:
> (...)
>
> try:
> (...)
>
> transaction:
> (...)
>
>
> Do you understand my concern?
I definetely see your point. However,...
> It would be very, very hard to discern
> these "user-defined statements" from real language constructs.
- today it is hard to distinguish a user-defined function
from a builtin function. What is the problem with the
former (anonymous blocks) that is accepted for the later (functions).
I guess the solution is the same for both: documentation.
- 'try' would probably be an invalid identifier/expression in a block,
as well as any other reserved words. So no confusion arises
from '''try:''' nor '''while''' nor '''for''' nor '''except''' etc
[ Ka-Ping Yee ]:
> My point is There are good reasons why the language has keywords, why it
> distinguishes statements from expressions, uses indentation, and
> so on. All of these properties cause Python programs to be made
> of familiar and easily recognizable patterns instead of degenerating
> into a homogeneous pile of syntax.
I am completely in favour of preserving Python's readability and simplicity.
But metaclasses and decorators introduced opportunities for some magical
spells. Either you know their definition and how they modify its subjects
or your code understanding might be harmed to a certain degree.
They were born without being baptized with a keyword, why should blocks ?
I think that the absence of 'name clashing', alone, is the strong argument
in favour of the __no keyword__ proposal.
Recognizing a __no keyword__ block would be very easy. If you did not
recognize it as something you already knew, then it was a block <0.2 wink>.
best regards,
Senra
--
Rodrigo Senra
--
MSc Computer Engineer rodsenra(at)gpr.com.br
GPr Sistemas Ltda http://www.gpr.com.br/
Personal Blog http://rodsenra.blogspot.com/
_______________________________________________
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
