Support multiple categories

[ssaamm]

In the iTunes spec, it seems like podcasts can live in up to 3 categories. Something like this would be awesome:

Podcast(
    # ...
    category=[Category('Technology'), Category('Business', 'Careers')]
)

But when I try that, I get a TypeError:

TypeError: A Category(-like) object must be used, got [Category(category=Technology, subcategory=None), Category(category=Business, subcategory=Careers)]

What do you think? Would you be open to a PR?

[tobinus]

Choosing the right category is probably one of the hardest thing to do when creating a podcast, because usually there's no "perfect" category. So I understand that it would be nice to select more than one. But Apple Podcasts does not support more than one category, as written in the page you link to:

Note: Although you can specify more than one category and subcategory in your RSS feed, Apple Podcasts only recognizes the first category and subcategory.

If there is any other podcast aggregator (like Spotify or Google Podcasts) that takes into account multiple categories, then I think it would be nice to be able to specify additional categories, in addition to the "main" category given to Apple Podcasts. But I think most vendors want to avoid abuse of the category feature, which could easily happen if every podcast could specify that they belong to every category :P Akin to the "tags" abuse that led YouTube to abolish tags on videos.

[ssaamm]

Huh, that's interesting. I saw a few sites claim you could use up to three categories (example, similar), but I wonder if Apple has changed that.

[tobinus]

Yes, that's weird. So I decided to do some research on this.

• Out of the current top 20 on Apple Podcasts, about eight podcasts had specified multiple categories.
• I tried browsing through podcasts using categories in Google Podcasts on my phone, and there were some shows that appeared in multiple categories.
• Spotify says in their spec that you can have any number of categories. And I could see that shows appeared in multiple categories in their app as well.

I think that's a good enough reason to add support for multiple categories.

But it seems that the first category listed in the RSS will hold some special significance. So I wonder if it would be best to split them into two attributes in PodGen's API, one being today's attribute and the other being a new attribute for additional categories? Something like

pod = Podcast()
# ...
pod.category = Category("Technology")

# Name of attribute is up for discussion
pod.additional_categories = {
    Category("Society & Culture", "Philosophy"),
    Category("News", "Tech News")
}

That way, it should be clear to everyone that they should be careful about what category they pick as their most important category. The name additional_categories is a bit long, though I prefer long and understandable over short and difficult to understand :)

Alternatively, we could make pod.category accept both a single Category and an iterable of Category (as in your suggestion). I don't like how it creates two ways of specifying one category (pod.category = Category("Technology") and pod.category = [Category("Technology")]), though it wouldn't be the first time something like that is done in PodGen. It is handy to have the first form as a shortcut for the latter (and for backwards compatibility).

The special meaning of the first category means you'd need to use an ordered collection (not a set), even though I think a set best represents the attribute (since each category should only appear once, and their order should not matter (except for the first one)). But maybe that's not so much of a problem.

Thoughts? :)

[ssaamm]

I like the latter approach simply because it was what I instinctively tried first. Still, I can see how the former makes more clear the significance of the first category.

Do you think the potential confusion of the latter approach could be mitigated in the docs?

[tobinus]

Well, if someone uses autocomplete in their IDE or just attempts to assign multiple categories to category and it had worked, they probably wouldn't have looked it up and learnt that the podcast is associated with just the first category on Apple Podcasts' listing for the podcast, right? I also see now that it doesn't make sense grammatically to assign multiple categories (plural) to an attribute named category (singular).

So I'd rather keep category the way it is now, and introduce a new attribute for the other categories that are not associated as strongly with the podcast.