search

earwig / mwparserfromhell

A Python parser for MediaWiki wikicode
https://mwparserfromhell.readthedocs.io/
MIT License
761 stars 75 forks source link

Proposal: Drop "from hell" from the name #123

Closed halfak closed 9 years ago

halfak commented 9 years ago

This library is pretty great and it seems like "mwparser" would be an appropriate name. It would make sense next to other libraries that implement the "mw" naming scheme. E.g. mwapi.

Advantages:

  1. It's a better name.
  2. Shorter name is easier to type and would reduce the need for aliasing on import (e.g. import mwparserfromhell as mwp) -- a common practice.

Disadvantages:

  1. Loss of backwards compatibility with scripts referencing the old name
  2. Lots of docs and references would need to be updated.

So, there's some benefits and drawbacks assuming you agree with me that that name "mwparser" is better.

ricordisamoa commented 9 years ago
  1. Easily mistakable with the original MediaWiki parser
  2. Loss of "halo of mystery"
yuna9 commented 9 years ago

FWIW, mwparser seems to already be taken on pypi: https://pypi.python.org/pypi/mwparser/?

halfak commented 9 years ago

Good point. I just emailed @paulproteus to see if he would be willing to give up the name on pypi.

lahwaacz commented 9 years ago

Names need to be unique. Combining generic terms such as mw + parser does not make much sense unless they are unique inside a (unique) namespace smaller than "world". How many "mwapi" clients are there already? It's better with parsers, but still...

halfak commented 9 years ago

I just got a positive response from @paulproteus. He's ready to let us have the name if we want it.

It seems that this parser is the dominant parser for MediaWiki stuff. There's only one "mwapi" package because names get enforced. There's also only one "mwoauth" and "mwxml".

paulproteus commented 9 years ago

I am super excited to see y'all's widely-used package stop calling itself "fromhell" and also super excited to hand over the mwparser name!

lahwaacz commented 9 years ago

There's only one "mwapi" package because names get enforced.

There is nothing unique about "mwapi", see https://www.mediawiki.org/wiki/API:Client_code. Or perhaps I should have said "distinguishable" instead of unique in my previous post...

It also seems that there is a "libmwparser" project, which most likely drops the "lib" prefix in its API and build process. https://www.mediawiki.org/wiki/Alternative_parsers

halfak commented 9 years ago

Indeed. But I don't think that argument suggests "mwparserfromhell" is a more appropriate name or that it somehow helps you differentiate it from "libmwparser" (which is clearly defunct).

If I go through the list of API libraries, I don't see a library that is meant to support only API use with a more specific name.

earwig commented 9 years ago

First off, thanks to @paulproteus for agreeing to let us use the name.

I think "from hell" is worth defending. It's inherently a little jokey, and emphasizes something important: mwpfh has to do a lot of wonky things that a proper MediaWiki parser doesn't, like making guesses about the syntactic contents of templates. MediaWiki is an awful language to work in this kind of offline, isolated scenario, hence the self-deprecating name: "this is not guaranteed to work the way you think!"

By calling it "mwparser" alone, we lose existing name recognition and are effectively making a claim that it's the definitive or ubiquitous MediaWiki parser. I can't do that in good conscience when things like Parsoid exist. (And mwpfh is Python-only, at that – pymwparser would be more acceptable, but that just sounds awkward to me.)

However – if people find the name offensive, that would be a good reason to change it, but so far no one's indicated to me that it is.

I would support some kind of aliasing setup, where people can import mwparser or import mpfh directly, but I'd prefer the real project name to remain the same. However, I'm not sure if this is considered good practice in the Python packaging community.

halfak commented 9 years ago

All good points.

Just to clarify, I did not propose the change for any reason other than I though the package deserved a simple, good name. I take no offense to the current name or use of "hell".

Prefixing "py" on the front of python packages is uncommon, but it seems to be common to prefix the project name on github with "python-" e.g. https://github.com/mediawiki-utilities/python-mwoauth.

I think that the incompleteness of the parser is good candidate reason for keeping the "from hell", since the suffix sort of implies that the library will be hard to use. But from a practical point of view, I've found the library to be more "from heaven" than hell for the problems I've solved with it.

earwig commented 9 years ago

I'm always glad to hear that people find this project useful.

I think I will close this issue for now. Maybe I will reconsider a name change when we reach version 1.0 and things are more stable. :smiley:

halfak commented 9 years ago

Make sense. Thanks for your consideration.

ghost commented 9 years ago

Shoutout to @halfak for mentioning ceterach.