Skip to content

Practical guidelines for beautiful Python code

turnkeylinux.org
36 pointsalonswartz3 comments
On HN

Comments

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)

#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.

> 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?

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.