Re: [Python-Dev] Official citation for Python
On Tue, Sep 11, 2018 at 3:48 AM, Steven D'Aprano wrote: > > That is about reproducible results, which is really a different thing > than > > the usual citations. > > I don't think it is. I think you are seeing a distinction that is not > there. no need for us to agree on that, but there are still multiple reasons / ways you might want to cite Python, and what you would want to cite would be different. Lets say one were to write an article about how different computer languages express functional programming concepts -- you may want to cite Python, but you are not trying to identify a specific version for reproducible results. And see Wes Turner's note -- it is highly unlikely that a single citation to a standard document or something will be enough for reproducibility anyway. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Python-Dev mailing list [email protected] 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
On Tue, Sep 11, 2018 at 11:16:08AM +0200, Chris Barker wrote:
> On Tue, Sep 11, 2018 at 3:48 AM, Steven D'Aprano
> wrote:
>
> > > That is about reproducible results, which is really a different thing
> > than
> > > the usual citations.
> >
> > I don't think it is. I think you are seeing a distinction that is not
> > there.
>
>
> no need for us to agree on that, but there are still multiple reasons /
> ways you might want to cite Python, and what you would want to cite would
> be different.
I think this thread is about *academic* citations. I know the feature
request I linked to earlier is, because I opened it and that's what I
intended :-)
Informal citations can include as much or as little information as you
care to give. It could be as little as "use Python" or it could be a
link to a specific branch or tag in a repo, complete with detailed
instructions on building the environment up to and including the OS and
processor type. But those sorts of detailed build instructions aren't
really a *citation*, they are more along the lines of the
experimental design ("First, compile Linux using gcc ...").
There's a metric ton of information on the web about citing software,
there are existing standards, and I really think you are
over-complicating this. See, for example:
https://www.software.ac.uk/how-cite-software
http://www.citethisforme.com/cite/software
https://openresearchsoftware.metajnl.com/about/#q12
Its not our job to tell academics how to cite, they already have a
number of standardised templates that they use, but it is our job to
tell them what information to fill into the template.
> Lets say one were to write an article about how different computer
> languages express functional programming concepts -- you may want to cite
> Python, but you are not trying to identify a specific version for
> reproducible results.
I don't think we need to lose any sleep over how random bloggers and
Redditors informally cite Python. I think the focus here is on academic
citations, which have rather precise and standard requirements. No need
to expand the scope of this problem to arbitrary mentions of Python.
Besides, if we have a sys.cite() function that provides the relevant
information, bloggers etc will soon learn to pick and choose the bits
they care about from it, even if they don't give a proper academic style
citation.
Of course it is possible that I've completely misunderstood Jackie's
request. If so, hopefully she will speak up soon.
> And see Wes Turner's note -- it is highly unlikely that a single citation
> to a standard document or something will be enough for reproducibility
> anyway.
The academic community seems to think that it is. We don't have to tell
them that they're wrong.
--
Steve
___
Python-Dev mailing list
[email protected]
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
On Sunday, September 9, 2018, Wes Turner wrote:
> "Python Programming Language" (van Rossum, et. Al)
>
> ?
>
> Should there be a URL and/or a DOI?
>
http://www.python.org/~guido/Publications.html
https://gvanrossum.github.io/Publications.html
lists a number of Python citations:
"""
Python
Guido van Rossum: Scripting the Web with Python. In "Scripting Languages:
Automating the Web", World Wide Web Journal, Volume 2, Issue 2, Spring
1997, O'Reilly.
Aaron Watters, Guido van Rossum, James C. Ahlstrom: Internet Programming
with Python. MIS Press/Henry Holt publishers, New York, 1996.
Guido van Rossum: Python Library Reference. May 1995. CWI Report CS-R9524.
Guido van Rossum: Python Reference Manual. May 1995. CWI Report CS-R9525.
Guido van Rossum: Python Tutorial. May 1995. CWI Report CS-R9526.
Guido van Rossum: Extending and Embedding the Python Interpreter. May 1995.
CWI Report CS-R9527.
Guido van Rossum, Jelke de Boer: Linking a Stub Generator (AIL) to a
Prototyping Language (Python). Spring 1991 EurOpen Conference Proceedings
(May 20-24, 1991) Tromso, Norway.
"""
https://en.wikipedia.org/wiki/History_of_Python#Version_release_dates cites
http://python-history.blogspot.com/2009/01/brief-timeline-of-python.html as
a reference (for Python versions up to 2.6 and 3.0):
- 0.9 - 1991
- 1.0 - 1994
- 2.0 - 2000
- 3.0 - 2008
- 3.7 - 2018
Maybe it would be most productive for us to discuss the fields in the
proposed citation?
~"PSF is the author"
@article{python,
title={{P}ython ...},
author={Van Rossum, G. and Python Software Foundation (PSF), The.} ,
journal={ },
volume={ },
pages={ },
year={ }
}
___
Python-Dev mailing list
[email protected]
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
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? > There's a metric ton of information on the web about citing software, > there are existing standards, and I really think you are > over-complicating this. See, for example: > > https://www.software.ac.uk/how-cite-software > > http://www.citethisforme.com/cite/software > > https://openresearchsoftware.metajnl.com/about/#q12 The fact that those posts exist demonstrates that this is anything but a solved problem. Its not our job to tell academics how to cite, they already have a > number of standardized templates that they use, but it is our job to > tell them what information to fill into the template. > yes, of course -- I don't know why this thread got sidetracked into citation formats, that has nothing to do with it. Or as the op said, that's "the easy part" > Lets say one were to write an article about how different computer > > languages express functional programming concepts -- you may want to cite > > Python, but you are not trying to identify a specific version for > > reproducible results. > > I don't think we need to lose any sleep over how random bloggers and > Redditors informally cite Python. Why in the world would you think "article" meant random bloggers? In BiBTex, for instance, a paper in a peer reviewed journal is called an "article", as apposed to a book, or chapter, or inproceedings, or techreport, or As this whole thread is about academic citations, I assumed that... I think the focus here is on academic > citations, which have rather precise and standard requirements. not for software, yet. > No need > to expand the scope of this problem to arbitrary mentions of Python. > I was not expanding it -- I was hoping to contract it -- or at least better define it. > Of course it is possible that I've completely misunderstood Jackie's > request. If so, hopefully she will speak up soon. I think we're all on the same page about that, actually. My point, to be more pedantic about it, is that an academic paper might be *about* Python in some way, or it might describe work that *used* Python as a tool to accomplish some other understanding. These *may* require a different citation. And a citation that satisfies academic criteria for using Python may not be enough to assure reproducible results. > And see Wes Turner's note -- it is highly unlikely that a single citation > > to a standard document or something will be enough for reproducibility > > anyway. > > The academic community seems to think that it is. We don't have to tell > them that they're wrong. The Academic community has a really bad track record with reproducible results for computationally based research -- it is not a solved problem. And it's not a "they" -- many of us on this list are part of the academic community. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Python-Dev mailing list [email protected] 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
Thanks Wes.
"""
> Python
>
> Guido van Rossum: Scripting the Web with Python. In "Scripting Languages:
> Automating the Web", World Wide Web Journal, Volume 2, Issue 2, Spring
> 1997, O'Reilly.
>
> Aaron Watters, Guido van Rossum, James C. Ahlstrom: Internet Programming
> with Python. MIS Press/Henry Holt publishers, New York, 1996.
>
> Guido van Rossum: Python Library Reference. May 1995. CWI Report CS-R9524.
>
> Guido van Rossum: Python Reference Manual. May 1995. CWI Report CS-R9525.
>
> Guido van Rossum: Python Tutorial. May 1995. CWI Report CS-R9526.
>
> Guido van Rossum: Extending and Embedding the Python Interpreter. May
> 1995. CWI Report CS-R9527.
>
> Guido van Rossum, Jelke de Boer: Linking a Stub Generator (AIL) to a
> Prototyping Language (Python). Spring 1991 EurOpen Conference Proceedings
> (May 20-24, 1991) Tromso, Norway.
> """
>
Of these, I think the Python Reference Manual is the only one that comes
close as a general citation for the langue itself. And it would be a
particular version, presumably. But those old versions are published as
tech reports by a know institution -- easier to cite than teh PSF.
I've seen folks cite various academic articles to satisfy a citation for a
language or library, but often that is simply because that is the one thing
they could find that is citable in the standard way.
sure -- though I don't think "article" is the correct catagory -- probbaly
technical report.
Looking at the current "official" docs, the copyright is held by the PSF,
but I see no author mentioned (I recall it said Fred Drake many years
back...) I take that back -- the PDF version has an author.
So I'm thinking maybe:
@techreport{techreport,
author = {Guido van Rossum and the Python development team},
title= {Python Language Reference, release 3.7.0},
institution = {Python Software Foundation},
year = 2018,
address = {9450 SW Gemini Dr. ECM# 90772, Beaverton, OR 97008 USA},
number = 3.7,
url .= {https://docs.python.org/release/3.7.0/},
}
I used "Guido van Rossum and the Python development team" as the Author, as
that's what it says on the PDF version. Not sure how bibliography software
will deal with that...
And what do we do with version? part of the title, or (ab)use number (Or
volume, or )
And it would be better to cite the entire standard docs, rather than just
the language reference, but I"m not sure what to call it -- there is no
single document with a title.
And a DOI for each release would be nice.
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[email protected]
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] bpo-34595: How to format a type name?
Hi,
Last week, I opened an issue to propose to add a new %T formatter to
PyUnicode_FromFormatV() and so indirectly to PyUnicode_FromFormat()
and PyErr_Format():
https://bugs.python.org/issue34595
I merged my change, but then Serhiy Storchaka asked if we can add
something to get the "fully qualified name" (FQN) of a type, ex
"datetime.timedelta" (FQN) vs "timedelta" (what I call "short" name).
I proposed a second pull request to add %t (short) in addition to %T
(FQN).
But then Petr Viktorin asked me to open a thread on python-dev to get
a wider discussion. So here I am.
The rationale for this change is to fix multiple issues:
* C extensions use Py_TYPE(obj)->tp_name which returns a fully
qualified name for C types, but the name (without the module) for
Python name. Python modules use type(obj).__name__ which always return
the short name.
* currently, many C extensions truncate the type name: use "%.80s"
instead of "%s" to format a type name
* "%s" with Py_TYPE(obj)->tp_name is used more than 200 times in the C
code, and I dislike this complex pattern. IMHO "%t" with obj would be
simpler to read, write and maintain.
* I want C extensions and Python modules to have the same behavior:
respect the PEP 399. Petr considers that error messages are not part
of the PEP 399, but the issue is wider than only error messages.
The main issue is that at the C level, Py_TYPE(obj)->tp_name is
"usually" the fully qualified name for types defined in C, but it's
only the "short" name for types defined in Python.
For example, if you get the C accelerator "_datetime",
PyTYPE(obj)->tp_name of a datetime.timedelta object gives you
"datetime.timedelta", but if you don't have the accelerator, tp_name
is just "timedelta".
Another example, this script displays "mytimedelta(0)" if you have the
C accelerator, but "__main__.mytimedelta(0)" if you use the Python
implementation:
---
import sys
#sys.modules['_datetime'] = None
import datetime
class mytimedelta(datetime.timedelta):
pass
print(repr(mytimedelta()))
---
So I would like to fix this kind of issue.
Type names are mainly used for two purposes:
* format an error message
* obj.__repr__()
It's unclear to me if we should use the "short" or the "fully
qualified" name. It should maybe be decided on a case by case basis.
There is also a 3rd usage: to implement __reduce__, here backward
compatibility matters.
Note: The discussion evolved since my first implementation of %T which
just used the not well defined Py_TYPE(obj)->tp_name.
--
Petr asked me why not exposing functions to get these names. For
example, with my second PR (not merged), there are 3 (private)
functions:
/* type.__name__ */
const char* _PyType_Name(PyTypeObject *type);
/* type.__qualname__ */
PyObject* _PyType_QualName(PyTypeObject *type);
* type.__module__ "." type.__qualname__ (but type.__qualname__ for
builtin types) */
PyObject * _PyType_FullName(PyTypeObject *type);
My concern here is that each caller has to handler error:
PyErr_Format(PyExc_TypeError, "must be str, not %.100s",
Py_TYPE(obj)->tp_name);
would become:
PyObject *type_name = _PyType_FullName(Py_TYPE(obj));
if (name == NULL) { /* do something with this error ... */
PyErr_Format(PyExc_TypeError, "must be str, not %U", type_name);
Py_DECREF(name);
When I report an error, I dislike having to handle *new* errors... I
prefer that the error handling is done inside PyErr_Format() for me,
to reduce the risk of additional bugs.
--
Serhiy also asked if we could expose the same feature at the *Python*
level: provide something to get the fully qualified name of a type.
It's not just f"{type(obj).__module}.{type(obj).__name__}", but you
have to skip the module for builtin types like "str" (not return
"builtins.str").
Maybe we can have "name: {0:t}, FQN: {0:T}".format(type(obj)). "t" for
name and "T" for fully qualfied name. We would only have to modify
type.__format__().
I'm not sure if we need to add new formatters to str % args.
Example of Python code:
raise TypeError("must be str, not %s" % type(fmt).__name__)
I'm not sure about Python changes. My first concern was just to avoid
Py_TYPE(obj)->tp_name at the C level. But again, we should keep C and
Python consistent. If the behavior of C extensions change, Python
modules should be adapted as well, to get the same behavior.
Note: I reverted my change which added the %T formatter from
PyUnicode_FromFormatV() to clarify the status of this issue.
Victor
___
Python-Dev mailing list
[email protected]
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?
On 09/11/18 15:23, Victor Stinner wrote:
Hi,
Last week, I opened an issue to propose to add a new %T formatter to
PyUnicode_FromFormatV() and so indirectly to PyUnicode_FromFormat()
and PyErr_Format():
https://bugs.python.org/issue34595
I merged my change, but then Serhiy Storchaka asked if we can add
something to get the "fully qualified name" (FQN) of a type, ex
"datetime.timedelta" (FQN) vs "timedelta" (what I call "short" name).
I proposed a second pull request to add %t (short) in addition to %T
(FQN).
But then Petr Viktorin asked me to open a thread on python-dev to get
a wider discussion. So here I am.
The rationale for this change is to fix multiple issues:
* C extensions use Py_TYPE(obj)->tp_name which returns a fully
qualified name for C types, but the name (without the module) for
Python name. Python modules use type(obj).__name__ which always return
the short name.
That might be a genuine problem, but I wonder if "%T" is fixing the
symptom rather than the cause here.
Or is this only an issue for PyUnicode_FromFormat()?
* currently, many C extensions truncate the type name: use "%.80s"
instead of "%s" to format a type name
That's an orthogonal issue -- you can change "%.80s" to "%s", and
presumably you could use "%.80t" as well.
* "%s" with Py_TYPE(obj)->tp_name is used more than 200 times in the C
code, and I dislike this complex pattern. IMHO "%t" with obj would be
simpler to read, write and maintain.
I consider `Py_TYPE(obj)->tp_name` much more understandable than "%t".
It's longer to spell out, but it's quite self-documenting.
* I want C extensions and Python modules to have the same behavior:
respect the PEP 399. Petr considers that error messages are not part
of the PEP 399, but the issue is wider than only error messages.
The other major use is for __repr__, which AFAIK we also don't guarantee
to be stable, so I don't think PEP 399 applies to it.
Having the same behavior between C and Python versions of a module is
nice, but PEP 399 doesn't prescribe it. There are other differences as
well -- for example, `_datetime.datetime` is immutable, and that's OK.
If error messages and __repr__s should be consistent between Python and
the C accelerator, are you planning to write tests for all the affected
modules when switching them to %T/%t?
The main issue is that at the C level, Py_TYPE(obj)->tp_name is
"usually" the fully qualified name for types defined in C, but it's
only the "short" name for types defined in Python.
For example, if you get the C accelerator "_datetime",
PyTYPE(obj)->tp_name of a datetime.timedelta object gives you
"datetime.timedelta", but if you don't have the accelerator, tp_name
is just "timedelta".
Another example, this script displays "mytimedelta(0)" if you have the
C accelerator, but "__main__.mytimedelta(0)" if you use the Python
implementation:
---
import sys
#sys.modules['_datetime'] = None
import datetime
class mytimedelta(datetime.timedelta):
pass
print(repr(mytimedelta()))
---
So I would like to fix this kind of issue.
Type names are mainly used for two purposes:
* format an error message
* obj.__repr__()
It's unclear to me if we should use the "short" or the "fully
qualified" name. It should maybe be decided on a case by case basis.
There is also a 3rd usage: to implement __reduce__, here backward
compatibility matters.
Note: The discussion evolved since my first implementation of %T which
just used the not well defined Py_TYPE(obj)->tp_name.
--
Petr asked me why not exposing functions to get these names. For
example, with my second PR (not merged), there are 3 (private)
functions:
/* type.__name__ */
const char* _PyType_Name(PyTypeObject *type);
/* type.__qualname__ */
PyObject* _PyType_QualName(PyTypeObject *type);
* type.__module__ "." type.__qualname__ (but type.__qualname__ for
builtin types) */
PyObject * _PyType_FullName(PyTypeObject *type);
My concern here is that each caller has to handler error:
PyErr_Format(PyExc_TypeError, "must be str, not %.100s",
Py_TYPE(obj)->tp_name);
would become:
PyObject *type_name = _PyType_FullName(Py_TYPE(obj));
if (name == NULL) { /* do something with this error ... */
PyErr_Format(PyExc_TypeError, "must be str, not %U", type_name);
Py_DECREF(name);
When I report an error, I dislike having to handle *new* errors... I
prefer that the error handling is done inside PyErr_Format() for me,
to reduce the risk of additional bugs.
--
Serhiy also asked if we could expose the same feature at the *Python*
level: provide something to get the fully qualified name of a type.
It's not just f"{type(obj).__module}.{type(obj).__name__}", but you
have to skip the module for builtin types like "str" (not return
"builtins.str").
Maybe we can have "name: {0:t}, FQN: {0:T}".format(type(obj)). "t" for
name and "T" for fully qualfied name. We would only have to modify
type.__format__().
I'm not sure if we need to add new formatters to str % args.
Example of Pyt
Re: [Python-Dev] bpo-34595: How to format a type name?
On 2018-09-11 23:23, Victor Stinner wrote:
Hi,
Last week, I opened an issue to propose to add a new %T formatter to
PyUnicode_FromFormatV() and so indirectly to PyUnicode_FromFormat()
and PyErr_Format():
https://bugs.python.org/issue34595
I merged my change, but then Serhiy Storchaka asked if we can add
something to get the "fully qualified name" (FQN) of a type, ex
"datetime.timedelta" (FQN) vs "timedelta" (what I call "short" name).
I proposed a second pull request to add %t (short) in addition to %T
(FQN).
But then Petr Viktorin asked me to open a thread on python-dev to get
a wider discussion. So here I am.
The rationale for this change is to fix multiple issues:
* C extensions use Py_TYPE(obj)->tp_name which returns a fully
qualified name for C types, but the name (without the module) for
Python name. Python modules use type(obj).__name__ which always return
the short name.
* currently, many C extensions truncate the type name: use "%.80s"
instead of "%s" to format a type name
* "%s" with Py_TYPE(obj)->tp_name is used more than 200 times in the C
code, and I dislike this complex pattern. IMHO "%t" with obj would be
simpler to read, write and maintain.
* I want C extensions and Python modules to have the same behavior:
respect the PEP 399. Petr considers that error messages are not part
of the PEP 399, but the issue is wider than only error messages.
The main issue is that at the C level, Py_TYPE(obj)->tp_name is
"usually" the fully qualified name for types defined in C, but it's
only the "short" name for types defined in Python.
For example, if you get the C accelerator "_datetime",
PyTYPE(obj)->tp_name of a datetime.timedelta object gives you
"datetime.timedelta", but if you don't have the accelerator, tp_name
is just "timedelta".
Another example, this script displays "mytimedelta(0)" if you have the
C accelerator, but "__main__.mytimedelta(0)" if you use the Python
implementation:
---
import sys
#sys.modules['_datetime'] = None
import datetime
class mytimedelta(datetime.timedelta):
pass
print(repr(mytimedelta()))
---
So I would like to fix this kind of issue.
Type names are mainly used for two purposes:
* format an error message
* obj.__repr__()
It's unclear to me if we should use the "short" or the "fully
qualified" name. It should maybe be decided on a case by case basis.
There is also a 3rd usage: to implement __reduce__, here backward
compatibility matters.
Note: The discussion evolved since my first implementation of %T which
just used the not well defined Py_TYPE(obj)->tp_name.
--
Petr asked me why not exposing functions to get these names. For
example, with my second PR (not merged), there are 3 (private)
functions:
/* type.__name__ */
const char* _PyType_Name(PyTypeObject *type);
/* type.__qualname__ */
PyObject* _PyType_QualName(PyTypeObject *type);
* type.__module__ "." type.__qualname__ (but type.__qualname__ for
builtin types) */
PyObject * _PyType_FullName(PyTypeObject *type);
My concern here is that each caller has to handler error:
PyErr_Format(PyExc_TypeError, "must be str, not %.100s",
Py_TYPE(obj)->tp_name);
would become:
PyObject *type_name = _PyType_FullName(Py_TYPE(obj));
if (name == NULL) { /* do something with this error ... */
PyErr_Format(PyExc_TypeError, "must be str, not %U", type_name);
Py_DECREF(name);
When I report an error, I dislike having to handle *new* errors... I
prefer that the error handling is done inside PyErr_Format() for me,
to reduce the risk of additional bugs.
--
Serhiy also asked if we could expose the same feature at the *Python*
level: provide something to get the fully qualified name of a type.
It's not just f"{type(obj).__module}.{type(obj).__name__}", but you
have to skip the module for builtin types like "str" (not return
"builtins.str").
Maybe we can have "name: {0:t}, FQN: {0:T}".format(type(obj)). "t" for
name and "T" for fully qualfied name. We would only have to modify
type.__format__().
I'm not sure if we need to add new formatters to str % args.
Example of Python code:
raise TypeError("must be str, not %s" % type(fmt).__name__)
I'm not sure about Python changes. My first concern was just to avoid
Py_TYPE(obj)->tp_name at the C level. But again, we should keep C and
Python consistent. If the behavior of C extensions change, Python
modules should be adapted as well, to get the same behavior.
Note: I reverted my change which added the %T formatter from
PyUnicode_FromFormatV() to clarify the status of this issue.
I'm not sure about having 2 different, though similar, format codes for
2 similar, though slightly different, cases. (And, for all we know, we
might want to use "%t" at some later date for something else.)
Perhaps we could have a single format code plus an optional '#' for the
"alternate form":
%T for short form
%#T for fully qualified name
___
Python-Dev mailing list
[email protected]
https://mail.python.org/ma
Re: [Python-Dev] bpo-34595: How to format a type name?
FWIW, I personally think this went to python-dev prematurely. This is a
shallow problem and IMO doesn't need all that much handwringing. Yes, there
are a few different alternatives. So list them all concisely in the tracker
and think about it for a few minutes and then pick one. No matter what's
picked it'll be better than the status quo -- which is that printing a
class name produces either a full or a short name depending on whether it's
defined in C or Python, and there's no simple pattern (in C) to print
either the full or the short name.
On Tue, Sep 11, 2018 at 4:09 PM MRAB wrote:
> On 2018-09-11 23:23, Victor Stinner wrote:
> > Hi,
> >
> > Last week, I opened an issue to propose to add a new %T formatter to
> > PyUnicode_FromFormatV() and so indirectly to PyUnicode_FromFormat()
> > and PyErr_Format():
> >
> > https://bugs.python.org/issue34595
> >
> > I merged my change, but then Serhiy Storchaka asked if we can add
> > something to get the "fully qualified name" (FQN) of a type, ex
> > "datetime.timedelta" (FQN) vs "timedelta" (what I call "short" name).
> > I proposed a second pull request to add %t (short) in addition to %T
> > (FQN).
> >
> > But then Petr Viktorin asked me to open a thread on python-dev to get
> > a wider discussion. So here I am.
> >
> >
> > The rationale for this change is to fix multiple issues:
> >
> > * C extensions use Py_TYPE(obj)->tp_name which returns a fully
> > qualified name for C types, but the name (without the module) for
> > Python name. Python modules use type(obj).__name__ which always return
> > the short name.
> >
> > * currently, many C extensions truncate the type name: use "%.80s"
> > instead of "%s" to format a type name
> >
> > * "%s" with Py_TYPE(obj)->tp_name is used more than 200 times in the C
> > code, and I dislike this complex pattern. IMHO "%t" with obj would be
> > simpler to read, write and maintain.
> >
> > * I want C extensions and Python modules to have the same behavior:
> > respect the PEP 399. Petr considers that error messages are not part
> > of the PEP 399, but the issue is wider than only error messages.
> >
> >
> > The main issue is that at the C level, Py_TYPE(obj)->tp_name is
> > "usually" the fully qualified name for types defined in C, but it's
> > only the "short" name for types defined in Python.
> >
> > For example, if you get the C accelerator "_datetime",
> > PyTYPE(obj)->tp_name of a datetime.timedelta object gives you
> > "datetime.timedelta", but if you don't have the accelerator, tp_name
> > is just "timedelta".
> >
> > Another example, this script displays "mytimedelta(0)" if you have the
> > C accelerator, but "__main__.mytimedelta(0)" if you use the Python
> > implementation:
> > ---
> > import sys
> > #sys.modules['_datetime'] = None
> > import datetime
> >
> > class mytimedelta(datetime.timedelta):
> > pass
> >
> > print(repr(mytimedelta()))
> > ---
> >
> > So I would like to fix this kind of issue.
> >
> >
> > Type names are mainly used for two purposes:
> >
> > * format an error message
> > * obj.__repr__()
> >
> > It's unclear to me if we should use the "short" or the "fully
> > qualified" name. It should maybe be decided on a case by case basis.
> >
> > There is also a 3rd usage: to implement __reduce__, here backward
> > compatibility matters.
> >
> >
> > Note: The discussion evolved since my first implementation of %T which
> > just used the not well defined Py_TYPE(obj)->tp_name.
> >
> > --
> >
> > Petr asked me why not exposing functions to get these names. For
> > example, with my second PR (not merged), there are 3 (private)
> > functions:
> >
> > /* type.__name__ */
> > const char* _PyType_Name(PyTypeObject *type);
> > /* type.__qualname__ */
> > PyObject* _PyType_QualName(PyTypeObject *type);
> > * type.__module__ "." type.__qualname__ (but type.__qualname__ for
> > builtin types) */
> > PyObject * _PyType_FullName(PyTypeObject *type);
> >
> > My concern here is that each caller has to handler error:
> >
> >PyErr_Format(PyExc_TypeError, "must be str, not %.100s",
> > Py_TYPE(obj)->tp_name);
> >
> > would become:
> >
> >PyObject *type_name = _PyType_FullName(Py_TYPE(obj));
> >if (name == NULL) { /* do something with this error ... */
> >PyErr_Format(PyExc_TypeError, "must be str, not %U", type_name);
> >Py_DECREF(name);
> >
> > When I report an error, I dislike having to handle *new* errors... I
> > prefer that the error handling is done inside PyErr_Format() for me,
> > to reduce the risk of additional bugs.
> >
> > --
> >
> > Serhiy also asked if we could expose the same feature at the *Python*
> > level: provide something to get the fully qualified name of a type.
> > It's not just f"{type(obj).__module}.{type(obj).__name__}", but you
> > have to skip the module for builtin types like "str" (not return
> > "builtins.str").
> >
> > Maybe we can have "name: {0:t}, FQN: {0:T}".format(type(obj)). "t" for
> > name and "T" for fully qualfied name. We would only have to modify
>
Re: [Python-Dev] bpo-34595: How to format a type name?
MRAB wrote on 9/11/18 16:06: On 2018-09-11 23:23, Victor Stinner wrote: Last week, I opened an issue to propose to add a new %T formatter to PyUnicode_FromFormatV() and so indirectly to PyUnicode_FromFormat() and PyErr_Format(): https://bugs.python.org/issue34595 I merged my change, but then Serhiy Storchaka asked if we can add something to get the "fully qualified name" (FQN) of a type, ex "datetime.timedelta" (FQN) vs "timedelta" (what I call "short" name). I proposed a second pull request to add %t (short) in addition to %T (FQN). But then Petr Viktorin asked me to open a thread on python-dev to get a wider discussion. So here I am. +1 for adding format specs for the types, and for giving a consistent way to specify which you want. %t (short) and %T (long) do seem like the logical choices, and I think in context it'll be pretty evident what they mean. Perhaps we could have a single format code plus an optional '#' for the "alternate form": %T for short form %#T for fully qualified name OTOH, if %T and variants meant "type" but %t mean something entirely different, that *would* probably be confusing. -Barry ___ Python-Dev mailing list [email protected] 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?
On 09/11/18 15:23, Victor Stinner wrote:
Hi,
Last week, I opened an issue to propose to add a new %T formatter to
PyUnicode_FromFormatV() and so indirectly to PyUnicode_FromFormat()
and PyErr_Format():
https://bugs.python.org/issue34595
I merged my change, but then Serhiy Storchaka asked if we can add
something to get the "fully qualified name" (FQN) of a type, ex
"datetime.timedelta" (FQN) vs "timedelta" (what I call "short" name).
I proposed a second pull request to add %t (short) in addition to %T
(FQN).
But then Petr Viktorin asked me to open a thread on python-dev to get
a wider discussion. So here I am.
After a discussion with Victor. I'll summarize where we are now.
There are actually two inconsistencies to fix:
- Python modules use `type(obj).__name__` and C extensions use
`Py_TYPE(obj)->tp_name`, which inconsistent.
- Usage __name__ or __qualname__, and prepending __module__ or not, is
inconsistent across types/modules.
It turns out that today, when you want to print out a type name, you
nearly always want the fully qualified name (including the module unless
it's "builtins"). So we can just have "%T" and not "%t". (Or we can add
"%t" if a use case arises).
It should be possible to do this also in Python, preferably using a name
similar to "%T".
Most of the usage is in error messages and __repr__, where we don't need
to worry about compatibility too much.
It should be possible to get the name if you have the type object, but
not an instance of it. So, the proposed `PyUnicode_FromFormat("%T",
obj)` is incomplete -- if we go that way, we'll also need a function
like PyType_GetFullName. Making "%T" work on the type, e.g.
`PyUnicode_FromFormat("%T", Py_TYPE(obj))`, would be more general.
---
So, I propose adding a "%T" formatter to PyUnicode_FromFormat, to be
used like this:
PyUnicode_FromFormat("%T", Py_TYPE(obj))
and a "T" format code for type.__format__, to be used like this:
f"{type(obj):T}"
___
Python-Dev mailing list
[email protected]
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?
On 09/11/2018 05:21 PM, Barry Warsaw wrote: MRAB wrote on 9/11/18 16:06: Perhaps we could have a single format code plus an optional '#' for the "alternate form": %T for short form %#T for fully qualified name OTOH, if %T and variants meant "type" but %t mean something entirely different, that *would* probably be confusing. I think folks used to %-formatting are already used to un-related but similar codes (and related but dissimilar): - %M for minute - %m for month (or maybe I have that backwards) - %H for 24-hour clock - %I for 12-hour clock - %w for weekday as decimal number - %W for week number of the year I always have to look it up. :( -- ~Ethan~ ___ Python-Dev mailing list [email protected] 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?
On 2018-09-12 02:00, Ethan Furman wrote: On 09/11/2018 05:21 PM, Barry Warsaw wrote: MRAB wrote on 9/11/18 16:06: Perhaps we could have a single format code plus an optional '#' for the "alternate form": %T for short form %#T for fully qualified name OTOH, if %T and variants meant "type" but %t mean something entirely different, that *would* probably be confusing. I think folks used to %-formatting are already used to un-related but similar codes (and related but dissimilar): - %M for minute - %m for month (or maybe I have that backwards) - %H for 24-hour clock - %I for 12-hour clock - %w for weekday as decimal number - %W for week number of the year I always have to look it up. :( Well, for the time of day (24-hour) it's %H:%M:%S, all uppercase. ___ Python-Dev mailing list [email protected] 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?
12.09.18 01:23, Victor Stinner пише:
But then Petr Viktorin asked me to open a thread on python-dev to get
a wider discussion. So here I am.
Thank you for opening this discussion Victor. I wanted to do it myself,
but you have wrote much better description of the problem. See also
related issues:
https://bugs.python.org/issue21861
https://bugs.python.org/issue22032 (solved)
https://bugs.python.org/issue22033 (solved)
https://bugs.python.org/issue27541 (solved)
https://bugs.python.org/issue28062
There were also attempts to change repr/str of types so that they return
just a FQN. It would help to solve the issue from Python side. This idea
was initially suggested by Guido, but later he changed his mind.
The rationale for this change is to fix multiple issues:
* C extensions use Py_TYPE(obj)->tp_name which returns a fully
qualified name for C types, but the name (without the module) for
Python name. Python modules use type(obj).__name__ which always return
the short name.
Sometimes Python modules use FQN, but this is not common, and the code
is cumbersome. It is more common to use obj.__class__ instead of
type(obj), the difference is intentionally ignored.
* currently, many C extensions truncate the type name: use "%.80s"
instead of "%s" to format a type name
AFAIK the rationale of this in PyUnicode_FromFormat() is that if you
have corrupted type object, tp_name can point on arbitrary place in
memory, and an attempt to interpret it as null terminated string can
output a large amount of trash. It is better to get a truncated type
name in error message (names of real types usually are below that limit)
than get tons of trash or an error in attempt to format it.
Maybe we can have "name: {0:t}, FQN: {0:T}".format(type(obj)). "t" for
name and "T" for fully qualfied name. We would only have to modify
type.__format__().
This will make the feature inconsistent in Python and C. In Python, the
argument is a type, in C it is an instance of the type. We need a way to
format a FQN in C for types themselves. It is less common case, but
using _PyType_FullName() for it is very non-convenient as you have shown
above.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
