[Python-ideas] Add a __cite__ method for scientific packages

Nick Coghlan ncoghlan at gmail.com
Sat Jun 30 04:47:01 EDT 2018


On 29 June 2018 at 12:14, Nathaniel Smith <njs at pobox.com> wrote:
> On Thu, Jun 28, 2018 at 2:25 PM, Andrei Kucharavy
> <andrei.kucharavy at gmail.com> wrote:
>> As for the list, reserving a __citation__/__cite__ for packages at the same
>> level as __version__ is now reserved and adding a citation()/cite() function
>> to the standard library seemed large enough modifications to warrant
>> searching a buy-in from the maintainers and the community at large.
>
> There isn't actually any formal method for registering special names
> like __version__, and they aren't treated specially by the language.
> They're just variables that happen to have a funny name. You shouldn't
> start using them willy-nilly, but you don't actually have to ask
> permission or anything.

The one caveat on dunder names is that we expressly exempt them from
our usual backwards compatibility guarantees, so it's worth getting
some level of "No, we're not going to do anything that would conflict
with your proposed convention" at the language design level.

> And it's not very likely that someone else
> will come along and propose using the name __citation__ for something
> that *isn't* a citation :-).

Aye, in this case I think you can comfortably assume that we'll
happily leave the "__citation__" and "__cite__" dunder names alone
unless/until there's a clear consensus in the scientific Python
community to use them a particular way.

And even then, it would likely be Python package installers like pip,
Python environment managers like pipenv, and data analysis environment
managers like conda that would handle the task of actually consuming
that metadata (in whatever form it may appear). Having your citation
management support depend on which version of Python you were using
seems like it would be mostly a source of pain rather than beneficial.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list