RetroSearch Browse

Wed May 4 19:30:21 CEST 2005 · https://mail.python.org/pipermail/python-dev/2005-May/053322.html

 [ Guido ]:
 > 1. Decide on a keyword to use, if any.

 Shouldn't be the other way around ?
 Decide to use *no* keyword, if that could be avoided. 

 In my large inexperience *no keyword* is much better (if feasible):

 1) No name conflicts with previous code: block, blocktemplate, whatever
 2) ':' is already a block (broader sense) indication
 3) Improved readbility:

    <<from PEP 340>>
    def locking_opening(lock, filename, mode="r"):
        block locking(lock):
            block opening(filename) as f:
                yield f

    <<from PEP 340>>
    def locking_opening(lock, filename, mode="r"):
        locking(lock):
            opening(filename) as f:
                yield f

 4) Better to make the language parser more complex than the language 
    exposed to end-users

 Following the PEP and this thread, it seems to me that __no keyword__
 is less preferable than __some keyword__(=='block' so far), and I wonder
 why is not the reverse. Perhaps I missed something ?

 Besides, I think this solves many issues AOP was trying to tackle in
 a much cleaner, elegant -- therefore pythonic -- way. Outstanding.

 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/

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2005-May/053322.html below:

[Python-Dev] PEP 340 -- loose ends