Symbols as parameters?

Jean-Michel Pichavant jeanmichel at sequans.com
Fri Jan 22 05:56:16 EST 2010


Steven D'Aprano wrote:
> (3) Then somone suggested to tie the constants to the function itself,
>> as in
>> def move(direction):
>>     print "moving %s" % direction
>>
>> move.UP = 'up'
>> move.DOWN = 'down'
>>
>> This is quite nice.
>>     
>
> I would call it a horrible, horrible, horrible code smell. A stench in 
> fact. In my opinion, such attributes tied to the function should be 
> treated as internal to the function, and not the public interface.
>
> I wouldn't go quite so far as to say they should be treated as private, 
> but having the caller use them should be rare and unusual.
>
>   
I don't think so, my solution is perfect :o)

Let me clarify, I wouldn't write this piece of code, but the OP seems to 
really worry about the 'noise' around its direction definitions. That is 
why I removed the constant class definition of DIRECTION, and add 
directly those constants in the function itself, allowing to use them 
without additional import statements. It is not usual but it is not 
*that* smelling.

def move(direction):
    """Move to the given direction.

    @param direction: one of the function constant move.UP or move.DOWN
    """
    print "moving %s" % direction
move.UP = 'up'
move.DOWN = 'down'


As soon as it is properly documented, as a public interface should be, 
it becomes an acceptable design, IMO. Not the design I would choose in 
normal circonstances though.

Jean-Michel




More information about the Python-list mailing list