Does Base content violate PEP 20

[Eric Moritz]

I started working on the category app and after implementing a sample
content object I started thinking that basecontent violates a number
of the PEP 20 rules, http://www.python.org/dev/peps/pep-0020/

Particularly these:
Explicit is better than implicit.
Simple is better than complex.
Flat is better than nested.
If the implementation is hard to explain, it's a bad idea.

For instance this is an implementation of a categorized content
object:

from pennypress.apps.category.models import CategoriesMixIn
from pennypress.apps.base.models import ContentBase


class FirstCategorizedContent(ContentBase, CategoriesMixIn):
pass


class SecondCategorizedContent(ContentBase, CategoriesMixIn):
pass

[Michael]

I don't think class inheritance is a violation of the Zen of Python. And I don't think this is hard to explain.

I haven't gotten a chance to look at your code yet, but I see this style of inheritance helping us out with generic code. As long as we are sorting on pub_date, we can use the same view for almost every model. This could be nice. 

We might want to eliminate mix-ins though (Even if they were my idea). I see there being issues with some class methods and Meta inheritance using multiple inherited classes. I am afraid we will bind ourselves if we hang out on the fringes of Django model inheritance. Again, not looking at code. 

[Eric]

My fear is that it hides the fields that the FirstCategorizedContent
model has. Looking at the models.py file gives me no insight into
what fields the model has. Therefore the code is implicit instead of
explicit. I would have to memorized the fields ContentBase and
CategoriesMixIn to know what fields the FirstCategorizedContent model
has or have to dig into the base model and mixin models.py's to find
out.

As far as the mix-ins go, I see them being handy for 90% of the
models. There will be fringe cases where the default field attributes
won't wanted and we'll need not use a mixin. For instance the
CategoriesMixIn has the field:

categories = models.ManyToManyField(Category, blank=True, null=True)

If we wanted to make the categories required we'd have to not use the
CategoriesMixIn. Not a big deal really, unless there is code checking
if a model inherits CategoriesMixIn. It would ignore that model.
Probably an argument against inheritance checking and for duck
typing. As long as the model follows the same interface template
(i.e. using the field name categories), the code can use duck typing
to assume the model's categories are stored there.

Even if the MixIn's aren't used to build a model, they provide a
template for models that don't use them. If someone writes a model
that deviates from the template they better have a good reason for it
otherwise they'll have to fix it.

We'll see how things go. That's all we can do. Implement and cross
our fingers :)

On May 28, 7:36 am, Michael <newmani...@gmail.com> wrote:

> On Wed, May 27, 2009 at 2:07 PM, Eric Moritz <eric.mor...@gmail.com> wrote:
>
> > I started working on the category app and after implementing a sample
> > content object I started thinking that basecontent violates a number

> > of the PEP 20 rules,http://www.python.org/dev/peps/pep-0020/

[Glenn Franxman]

I think its a matter of degrees.

If all "content" is going to extend BaseContent, then we should probably just make BaseContent fairly explicit.

Want to avoid:

class MyContent( SomeMixin, OtherMixin, NextMixin, ObscureMixin, OverrrideUnneededBaseMethodsMixin, BaseContent ):
     pass

Reuse is handy and dry, but readability and comprehension probably trump.  Unless all of those mixins are going to get used independently elsewhere, or we can reasonably expect them to get isolated use elsewhere, I would just make them explicit parts of base.

At least we have multiple inheritance and mixins.    My least favarite part of the java frameworks were all the intermediate classes:

class MyAbstract impliment MyIF
...
class MyImpl extends MyAbstract
...
class NotYetUseful extends MyImpl
...
class Usable extend NotYetUseful

[Eric]

Yeah I doubt we'll see any more mixins than what we have in the base
app right now. In fact, I'm iffy about the CategoryMixIn and
CategoriesMixIn I implemented in the categories branch. They seem to
be overkill since they really only provide one field to the child
class. That's an interface that we can enforce via communication and
not necessary via a mixin. We should probably define some rules for
when a mixin is beneficial and when it's not.
E.

On May 27, 2:07 pm, Eric Moritz <eric.mor...@gmail.com> wrote:
> I started working on the category app and after implementing a sample
> content object I started thinking that basecontent violates a number

> of the PEP 20 rules,http://www.python.org/dev/peps/pep-0020/