
Practical guidelines for beautiful Python code - alonswartz
http://www.turnkeylinux.org/blog/beautiful-python-code
======
deno
I'm not sure about #2. Is it really that good idea to extend types? Or to be
precise — to extend non-abstract classes?

It leads to unintuitive behavior:

    
    
        >>> IntField(5, 'abc') is IntField(5, 'abc')
        False
    

whereas

    
    
        >>> int(5) is int(5)
        True
    

also:

    
    
        >>> IntField(5, 'abc') == 5
        True
    

not to mention:

    
    
        >>> IntField(5, 'abcd') == IntField(5, 'xyz')
        True
    
    

IMO this would be better, more flexible approach:

    
    
        class MyIntField(object):
            @property
            def val(self):
                return self._val
    
            @property
            def name(self):
                return self._name
    
            def __init__(self, val, name):
                self._val = val
                self._name = name
    
            def __eq__(self, other):
    	          	return (self.val == other.val) and \
                       (self.name == other.name)

------
lincolnq
#1, "Object Oriented structure should always map to well defined mental
concepts in the problem domain," is a recipe for producing excessively complex
code. You end up focusing on the parts themselves, instead of their
interactions, which is actually the important part.

~~~
deno
> You end up focusing on the parts themselves, instead of their interactions,
> which is actually the important part.

Aren't interactions on what CRC cards put emphasis?

