Page MenuHomePhabricator

Allow additional characters in family class name
Open, Needs TriagePublic

Description

A list of acceptable characters for the name attribute of a family class was added in e6e1e17f. We've had requests for _ and . to be added to the list. I have no objections to sensible additions, but would prefer that we move towards the filename and class name and class attribute name all being aligned.

Event Timeline

jayvdb created this task.Jun 25 2015, 10:38 AM
jayvdb raised the priority of this task from to Needs Triage.
jayvdb updated the task description. (Show Details)
jayvdb added a project: Pywikibot.
jayvdb added subscribers: jayvdb, Gallaecio.
Restricted Application added subscribers: pywikibot-bugs-list, Aklapper. · View Herald TranscriptJun 25 2015, 10:38 AM
XZise added a subscriber: XZise.Jun 25 2015, 10:41 AM

If we align with the class name, we can't support . and shouldn't support _ (at least it's not PEP8 compliant). Can someone explain why they would want to use .?

I am probably the only one suggesting ".", and I guess that I can live without it. In fact, I guess that I could live without _ as well.

Well primarily I'm interested in why you want to allow that character. Maybe there is a good reason or something and at the moment all families use the name “Family” as the class name.

The class name are current required to be Family I think, but I would like to break that requirement and allow the class name to be WikipediaFamily with a name attribute of wikipedia.

@Gallaecio, would it help if we added subdirectory/subpackage support, so you could have your own package pywikibot.families.foo which contains a set of family files (and that package could be managed on pypi even)?

I was talking about the codename, the one that you pass to the -family parameter. To refer to our wikis, before I even started using PyWikiBot, we had codes such as "xe8.lib" to refer to certain wikis. When I started using PyWikiBot, I decided to stick to those names, and since it was possible, I did so. But I could use "xe8lib" instead.

My main concern is separation between the families of the wikis of my company and the public families of PyWikiBot. Specially because, although unlikely, name collision would be possible. And, given a name collision, I would like my custom family files to take precedence over those of PyWikiBot. As long as that is possible, a subpackage within the families folder would certainly be an option.

Later today I will review the actual implementation that I have for family files (I generate them by script from some INI files that we have, so I’m not familiar with the actual implementation), to see if there is anything else that may be a problem. But I do not mind making changes on my end as needed.

Checked, I don't do anything special on those family files, no issues on my side with this change.

My patch (https://gerrit.wikimedia.org/r/#/c/220409/) allows custom family to take precedence, as register_families_folder('custom_folder') will replace existing ones registered earlier from register_families_folder('pywikibot/families').

On two related changes (https://gerrit.wikimedia.org/r/#/c/221119 and https://gerrit.wikimedia.org/r/#/c/221116) we're discussing, among other things, whether it will be useful to have multiple classes in a single module. I suspect this will be simpler for some families. e.g. with https://gerrit.wikimedia.org/r/#/c/219617/, the Wikimedia meta-family becomes much less complicated, and after that patch is another patch (not yet submitted) that defines the interwiki_forward rule in one place, which causes most of the Wikimedia families to become only two attributes: name and domain.

fyi: I don't see the usefulness of interwiki_forward with APISite.interwiki and would like if we could get rid of it to make the Family class simpler.

fyi: I don't see the usefulness of interwiki_forward with APISite.interwiki and would like if we could get rid of it to make the Family class simpler.

Started a discussion about that at T104129, and there is also related T104125: interwiki_forwarded_from is unimplemented.