Re: [Python-Dev] Official citation for Python
On Tue, Sep 11, 2018 at 10:35:04PM +0200, Chris Barker wrote: > On Tue, Sep 11, 2018 at 2:45 PM, Steven D'Aprano > wrote: > > > I think this thread is about *academic* citations. > > yes, I assumed that as well, what in any of my posts made you think > otherwise? When you started talking about *articles* rather than *papers*. Articles are far more general and include anything up to and including posts on Reddit. Anyway, I think until Jackie returns to clarify what precisely she hopes to gain, I don't think further discussion on-list is warranted. -- 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/archive%40mail-archive.com
[Python-Dev] Stop automerging
12.09.18 01:34, Miss Islington (bot) пише: https://github.com/python/cpython/commit/d13e59c1b512069d90efe7ee9b613d3913e79c56 commit: d13e59c1b512069d90efe7ee9b613d3913e79c56 branch: master author: Benjamin Peterson committer: Miss Islington (bot) <31488909+miss-isling...@users.noreply.github.com> date: 2018-09-11T15:29:57-07:00 summary: Make sure the line comes from the same node as the col offset. (GH-9189) Followup to 90fc8980bbcc5c7dcced3627fe172b0bfd193a3b. This commit message looks awful (and it is duplicated in maintained branches). Please stop automerging to master by bots. The reason of automating merging before is that the core dev that performs merging is responsible for editing the commit message. There were mistakes from time to time, but usually regular commiters did care of this. I often use "git log", and such commit messages spoil the history. ___ 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
Re: [Python-Dev] Stop automerging
It is still up to the core dev to set the message properly, but the HTML comments are invisible on GitHub until you edit the message. That bug is now fixed, though; HTML comments are stripped from the message before creating the commit. -- Zach (Top-posted in HTML from a phone) On Wed, Sep 12, 2018, 01:34 Serhiy Storchaka wrote: > 12.09.18 01:34, Miss Islington (bot) пише: > > > https://github.com/python/cpython/commit/d13e59c1b512069d90efe7ee9b613d3913e79c56 > > commit: d13e59c1b512069d90efe7ee9b613d3913e79c56 > > branch: master > > author: Benjamin Peterson > > committer: Miss Islington (bot) < > 31488909+miss-isling...@users.noreply.github.com> > > date: 2018-09-11T15:29:57-07:00 > > summary: > > > > Make sure the line comes from the same node as the col offset. (GH-9189) > > > > Followup to 90fc8980bbcc5c7dcced3627fe172b0bfd193a3b. > > > > > > This commit message looks awful (and it is duplicated in maintained > branches). Please stop automerging to master by bots. The reason of > automating merging before is that the core dev that performs merging is > responsible for editing the commit message. There were mistakes from > time to time, but usually regular commiters did care of this. > > I often use "git log", and such commit messages spoil the history. > > ___ > 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/zachary.ware%2Bpydev%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
Re: [Python-Dev] Stop automerging
Thanks Zach for fixing it quickly. Even if that bug has been fixed, per my instructions to python-committers, core devs should still edit the PR title and PR description *before* adding the '🤖 automerge' label. The YouTube video (link in python-committers email) shows to edit those. The PR title and body will be used as the squashed commit message. And remember, you can still merge the PR manually. Just don't apply the '🤖 automerge' label. On Wed, Sep 12, 2018, 2:09 AM Zachary Ware wrote: > It is still up to the core dev to set the message properly, but the HTML > comments are invisible on GitHub until you edit the message. That bug is > now fixed, though; HTML comments are stripped from the message before > creating the commit. > > ___ 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
Re: [Python-Dev] Stop automerging
On Wed, Sep 12, 2018, at 01:33, Serhiy Storchaka wrote: > 12.09.18 01:34, Miss Islington (bot) пише: > > https://github.com/python/cpython/commit/d13e59c1b512069d90efe7ee9b613d3913e79c56 > > commit: d13e59c1b512069d90efe7ee9b613d3913e79c56 > > branch: master > > author: Benjamin Peterson > > committer: Miss Islington (bot) > > <31488909+miss-isling...@users.noreply.github.com> > > date: 2018-09-11T15:29:57-07:00 > > summary: > > > > Make sure the line comes from the same node as the col offset. (GH-9189) > > > > Followup to 90fc8980bbcc5c7dcced3627fe172b0bfd193a3b. > > > > > > This commit message looks awful (and it is duplicated in maintained > branches). Please stop automerging to master by bots. The reason of > automating merging before is that the core dev that performs merging is > responsible for editing the commit message. There were mistakes from > time to time, but usually regular commiters did care of this. (Just checking) Is there something wrong with this message besides the <-- comment? ___ 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
Re: [Python-Dev] Stop automerging
Hi Benjamin, https://github.com/python/cpython/commit/d13e59c1b512069d90efe7ee9b613d3913e79c56 Le mer. 12 sept. 2018 à 17:19, Benjamin Peterson a écrit : > (Just checking) Is there something wrong with this message besides the <-- > comment? Since the commit is described as a follow-up of 90fc8980bbcc5c7dcced3627fe172b0bfd193a3b, maybe it could also include "bpo-31902: " prefix in it's title. Just to ease following where the change comes from. IMHO the main complain of Serhiy was the giant comment ;-) I agree that this one has to go, and hopefully it's already fixed. We are now good! Victor ___ 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
Re: [Python-Dev] Stop automerging
Oh yes, one issue of missing bpo-xxx is that bots don't report merged commits into the bpo. I like using the bpo issue to track backports: https://bugs.python.org/issue31902 It was just a general remark, it's fine for these commits. Someone can add them manually to the bpo if you want. Victor Le mer. 12 sept. 2018 à 17:56, Victor Stinner a écrit : > > Hi Benjamin, > > https://github.com/python/cpython/commit/d13e59c1b512069d90efe7ee9b613d3913e79c56 > > Le mer. 12 sept. 2018 à 17:19, Benjamin Peterson a > écrit : > > (Just checking) Is there something wrong with this message besides the <-- > > comment? > > Since the commit is described as a follow-up of > 90fc8980bbcc5c7dcced3627fe172b0bfd193a3b, maybe it could also include > "bpo-31902: " prefix in it's title. Just to ease following where the > change comes from. > > IMHO the main complain of Serhiy was the giant comment > ;-) I agree that this one has to go, and hopefully it's already fixed. > We are now good! > > Victor ___ 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
Re: [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods
On 06/20/18 01:53, Jeroen Demeyer wrote: Hello, Let me present PEP 579 and PEP 580. PEP 579 is an informational meta-PEP, listing some of the issues with functions/methods implemented in C. The idea is to create several PEPs each fix some part of the issues mentioned in PEP 579. PEP 580 is a standards track PEP to introduce a new "C call" protocol, which is an important part of PEP 579. In the reference implementation (which is work in progress), this protocol will be used by built-in functions and methods. However, it should be used by more classes in the future. You find the texts at https://www.python.org/dev/peps/pep-0579 https://www.python.org/dev/peps/pep-0580 Hi! I finally had time to read the PEPs carefully. Overall, great work! PEP 580 does look complicated, but it's well thought out and addresses real problems. I think the main advantage over the competing PEP 576 is that it's a better foundation for solving Cython (and other C-API users) and my PEP 573 (module state access from methods). With that, I do have some comments. The reference to PEP 573 is premature. If PEP 580 is implemented then PEP 573 will build on top, and I don't plan to update PEP 573 before that. So, I think 580 should be independent. If you agree I can summarize rationale for "parent", as much as it concerns 580. # Using tp_print The tp_print gimmick is my biggest worry. AFAIK there's no guarantee that a function pointer and Py_ssize_t are the same size. That makes the backwards-compatibility typedef in the implementation is quite worrying: typedef Py_ssize_t printfunc I can see the benefit for backporting to earlier Python versions, and maybe that outweighs worries about exotic architectures, but the PEP should at least have more words on why this is not a problem. # The C Call protocol I really like the fact that, in the reference implementation, the flags are arranged in a way that allows a switch statement to select what to call. That should be noted, if only to explain why there's no guarantee of compatibility between Python versions. # Descriptor behavior I'd say "SHOULD" rather than "MUST" here. The section describes how to implement expected/reasonable behavior, but I see no need to limit that. "if func supports the C call protocol, then func.__set__ must not be implemented." -- also, __delete__ should not be implemented, right?. # Generic API functions I'm a bit worried about PyCCall_FASTCALL's "kwds" argument accepting a dict, which is mutable. I wouldn't mind dropping that capability, but if it stays, we need to require that the callable promises to not modify it. PyCCall_FASTCALL is not a macro, shouldn't it be named PyCCall_FastCall? # C API functions The function PyCFunction_GetFlags is, for better or worse, part of the stable ABI. We shouldn't just give up on it. I'm fine with documenting that it shouldn't be used, but for functions defined using PyCFunction_New etc. it should continue behaving as before. One solution could be to preserve the "definition time" METH_* flags in the 0xFFF bits of cc_flags and use the other bits for CCALL_*. # Stable ABI The section should repeat that PyCFunction_ClsNew is added to the stable ABI (but nothing else). ___ 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
Re: [Python-Dev] bpo-34595: How to format a type name?
Hi,
For the type name, sometimes, we only get a type (not an instance),
and we want to format its FQN. IMHO we need to provide ways to format
the FQN of a type for *types* and for *instances*. Here is my
proposal:
* Add !t conversion to format string
* Add ":T" format to type.__format__()
* Add "%t" and "%T" formatters to PyUnicode_FromUnicodeV()
* Add a read-only type.__fqn__ property
# Python: "!t" for instance
raise TypeError(f"must be str, not {obj!t}")
/* C: "%t" for instance */
PyErr_Format(PyExc_TypeError, "must be str, not %t", obj);
/* C: "%T" for type */
PyErr_Format(PyExc_TypeError, "must be str, not %T", mytype);
# Python: ":T" for type
raise TypeError(f"must be str, not {mytype!T}")
Open question: Should we also add "%t" and "%T" formatters to the str
% args operator at the Python level?
I have a proof-of-concept implementation:
https://github.com/python/cpython/pull/9251
Victor
Victor
___
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
Re: [Python-Dev] Official citation for Python
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] 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
Re: [Python-Dev] Official citation for Python
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] > 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
Re: [Python-Dev] Official citation for Python
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 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] >> 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, Anacon
