[Python-Dev] PEP 340 -- loose ends

Rodrigo Dias Arruda Senra rodsenra at gpr.com.br
Wed May 4 23:29:47 CEST 2005


[ 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/



More information about the Python-Dev mailing list