There was a thread about adding __cite__ to things and a tool to collect those citations awhile back.
"[Python-ideas] Add a __cite__ method for scientific packages" http://markmail.org/thread/rekmbmh64qxwcind Which CPython source file should contain this __cite__ value? ... On a related note, you should ask the list admin to append a URL to each mailing list message whenever this list is upgraded to mm3; so that you can all be appropriately cited. On Thursday, September 13, 2018, Wes Turner <wes.tur...@gmail.com> wrote: > Do you guys think we should all cite Grub and BusyBox and bash and libc > and setuptools and pip and openssl and GNU/Linux and LXC and Docker; or > else it's plagiarism for us all? > > #OpenAccess > > On Wednesday, September 12, 2018, Stephen J. Turnbull < > turnbull.stephen...@u.tsukuba.ac.jp> wrote: > >> Chris Barker via Python-Dev writes: >> >> > But "I wrote some code in Python to produce these statistics" -- >> > does that need a citation? >> >> That depends on what you mean by "statistics" and whether (as one >> should) one makes the code available. If the code is published or >> "available on request", definitely, Python should be cited. If not, >> and by "statistics" you mean the kind of things provided by Steven >> d'Aprano's excellent statistics module (mean, median, standard >> deviation, etc), maybe no citation is needed. But anything more >> esoteric than that (even linear regression), yeah, I would say you >> should cite both Python and any reference you used to learn the >> algorithm or formulas, in the context of mentioning that your >> statistics are home-brew, not produced by one of the recognized >> applications for doing so. >> >> > If so, maybe that would take a different form. >> >> Yes, it would. But not so different: eg, version is analogous to >> edition when citing a book. >> >> > Anyway, hard to make this decision without some idea how the >> > citation is intended to be used. >> >> Same as any other citation, (1) to give credit to those responsible >> for providing a resource (this is why publishers and their metadata of >> city are still conventionally included), and (2) to show where that >> resource can be obtained. AFAICS, both motivations are universally >> applicable in polite society. NB: Replication is an important reason >> for wanting to acquire the resource, but it's not the only one. >> >> I think underlying your comment is the question of *what* resource is >> being cited. I can think of three offhand that might be characterized >> as "Python". First, the PSF, as a provider of funding. There is a >> conventional form for this: a footnote on the title or author's name >> saying "The author acknowledges [a] <purpose of grant such as travel> >> grant [grant identifier if available] from the Python Software >> Foundation." I usually orally mention them in presentations, too. >> That one's easy; *everybody* should *always* do that. >> >> The rest of these, sort of an ideal to strive for. If you keep a >> bibliographic database, and there are now quite a few efforts to crowd >> source them, it's easier to go the whole 9 yards than to skimp. But >> except in cases where we don't need to even mention the code, probably >> we should be citing, for reasons of courtesy to readers as well as >> authors, editors, and publishers (as disgusting as many publishers are >> as members of society, they do play a role in providing many resources >> ---we should find ways to compete them into good behavior, not >> ostracize them). >> >> The second is the Python *language and standard library*. Then the >> Language Reference and/or the Library Reference should be cited >> briefly when Python is first mentioned, and in the text introducing a >> program or program fragment, with a full citation in the bibliography. >> I tentatively suggest that the metadata for the Language Reference >> would be >> >> Author: principal author(s) (Guido?) et al. OR python.org OR >> Python Contributors >> Title: The Python Language Reference >> Version: to match Python version used (if relevant, different >> versions each get full citations), probably should not be >> "current" >> Publisher: Python Software Foundation >> Date: of the relevant version >> Location: City of legal address of PSF >> URL: to version used (probably should not be the default) >> Date accessed: if "current" was used >> >> The Library reference would be the same except for Title. >> >> The third is a *particular implementation*. In that case the metadata >> would be >> >> Author: principal author(s) (Guido) et al. OR python.org OR >> Python Contributors >> Title: The cPython Python distribution >> Python Version: as appropriate (if relevant, different versions each >> get full citations), never "current" >> Distributor Version: if different from Python version (eg, additional >> Debian cruft) >> Publisher: Distributor (eg, PSF, Debian Project, Anaconda Inc.) >> Date: of the relevant version >> Location: City of legal address of distributor >> >> If downloaded: >> >> URL: to version used (including git commit SHA1 if available) >> Date accessed: download from distributor, not installation date >> >> If received on physical medium: use the "usual" form of citation for a >> collection of individual works (even if Python was the only thing on >> it). Probably the only additional information needed would be the >> distributor as editor of the collection and the name of the >> collection. >> >> In most cases I can think of, if the implementation is cited, the >> Language and Library References should be cited, too. >> >> Finally, if Python or components were modified for the project, the >> modified version should be preserved in a repository and a VCS >> identifier provided. This does not imply the repository need be >> publicly accessible, of course, although it might be for other reasons >> (eg, in a GSoC project,wherever or if hosted for free on GitHub). >> >> I doubt that "URNs" like DOI and ISBN are applicable, but if available >> they should be included in all cases as well. >> >> Steve >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes. >> turner%40gmail.com >> >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
