Re: [Python-Dev] bpo-34595: How to format a type name?
On 13 Sep 2018, at 2:33, Victor Stinner wrote:
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()
As far as I can remember, the distinction between lowercase and
uppercase format letter for PyUnicode_FromUnicodeV() and friends was:
lowercase letters are for formatting C types (like `char *` etc.) and
uppercase formatting letters are for Python types (i.e. the C type is
`PyObject *`). IMHO we should keep that distinction.
* Add a read-only type.__fqn__ property
I like that.
# 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}")
We could solve the problem with instances and classes by adding two new
! operators to str.format/f-strings and making them chainable. The !t
operator would get the class of the argument and the !c operator would
require a class argument and would convert it to its name (which is
obj.__module__ + "." + obj.__qualname__ (or only obj.__qualname__ for
builtin types)). So:
>>> import pathlib
>>> p = pathlib.Path("spam.py")
>>> print(f"{pathlib.Path}")
>>> print(f"{pathlib.Path!c}")
pathlib.Path
>>> print(f"{pathlib.Path!c!r}")
'pathlib.Path'
>>> print(f"{p!t}")
>>> print(f"{p!t!c}")
pathlib.Path
>>> print(f"{p!c}")
Traceback (most recent call last):
File "", line 1, in
TypeError: object is not a class
This would also give us:
>>> print(f"{p!s!r}")
'spam.py'
Which is different from:
>>> print(f"{p}")
spam.py
>>> print(f"{p!r}")
PosixPath('spam.py')
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
Servus,
Walter
___
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] PEP 579 and PEP 580: refactoring C functions and methods
On 2018-09-13 02:26, Petr Viktorin wrote: The reference to PEP 573 is premature. It seems to me that PEP 580 helps with the use case of PEP 573. In fact, it implements part of what PEP 573 proposes. So I don't see the problem with the reference to PEP 573. Even if the implementation of PEP 573 changes, the problem statement will remain and that's what I'm referring to. If you agree I can summarize rationale for "parent", as much as it concerns 580. Sure. I still think that we should refer to PEP 573, but maybe we can summarize it also in PEP 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. I'm not actually claiming anywhere that it is the same size. # 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. There *is* actually an important reason to limit it: it allows code to make assumptions on what __get__ does. This enables optimizations which wouldn't be possible otherwise. If you cannot be sure what __get__ does, then you cannot optimize obj.method(x) to type(obj).method(obj, x) "if func supports the C call protocol, then func.__set__ must not be implemented." -- also, __delete__ should not be implemented, right?. Indeed. I write Python but I think C API, so for me these are both really tp_descr_set. PyCCall_FASTCALL is not a macro, shouldn't it be named PyCCall_FastCall? What's the convention for that anyway? I assumed that capital letters meant a "really know what you are doing" function which could segfault if used badly. For me, whether something is a function or macro is just an implementation detail (which can change between Python versions) which should not affect the naming. # 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_*. I'm fine with that if you insist. However, it would be a silly solution to formally satisfy the "stable ABI" requirement without actually helping. I agree with your other points that I didn't reply to and will make some edits to PEP 580. Jeroen. ___ 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 9/12/2018 8:33 PM, Victor Stinner wrote:
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
I'm strongly opposed to this. This !t conversion would not be widely
applicable enough to be generally useful, and would need to be exposed
in the f-string and str.format() documentation, even though 99% of
programmers would never need or see it. The purpose of the conversions
is not to save you from making a function call when you know the type of
the arguments. The purpose was specifically to convert arguments to
strings so that your format specifier could always use the string
formatting mini-language. It was more useful in str.format(), where the
format string might be written separately (as user input or a
translation, say) and not know the types of the arguments. You can (and
I have!) argued that the conversions are completely unneeded in f-strings.
raise TypeError(f"must be str, not {obj!t}")
Should be written as:
raise TypeError(f"must be str, not {type(obj)}")
* Add ":T" format to type.__format__()
As you know (I've read the patch) this is just "T". I mention it here
for future readers. They should understand that the ":" is a
str.format() and f-string construct, and is unknown to __format__().
That said, I think this is a good idea. type.__format__() could also
understand "#" to specify qualname.
* Add "%t" and "%T" formatters to PyUnicode_FromUnicodeV()
I think "T" is a good idea, but I think you're adding in obj vs
type(obj) just because of the borrowed reference issue in Py_TYPE().
That issue is so much larger than string formatting the type of an
object that it shouldn't be addressed here.
* Add a read-only type.__fqn__ property
I'm not sure of the purpose of this. When in your examples is it used?
# 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?
No. Again, I think any formatting of type names should not be in a
widely used interface, and should remain in our type-specific interface,
__format__. %-formatting has no per-type extensibility, and I don't
think we should start adding codes for every possible use case. Format
codes for datetimes would be way more useful that %t, and I'd be opposed
to adding them, too. (I realize my analogy is stretched, because every
object has a type. But still.)
Eric
I have a proof-of-concept implementation:
https://github.com/python/cpython/pull/9251
Victor
Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
___
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] PEP 579 and PEP 580: refactoring C functions and methods
On 09/13/18 02:22, Jeroen Demeyer wrote: On 2018-09-13 02:26, Petr Viktorin wrote: The reference to PEP 573 is premature. It seems to me that PEP 580 helps with the use case of PEP 573. In fact, it implements part of what PEP 573 proposes. So I don't see the problem with the reference to PEP 573. Even if the implementation of PEP 573 changes, the problem statement will remain and that's what I'm referring to. If you agree I can summarize rationale for "parent", as much as it concerns 580. Sure. I still think that we should refer to PEP 573, but maybe we can summarize it also in PEP 580. I want to make it clear that PEP 580 doesn't depend on 579. Reviewers don't need to agree with PEP 579 to accept 580. Here's my proposed rewording: https://github.com/python/peps/pull/775/files?short_path=b34f00e#diff-b34f00eeb75773c32f9b22fd7fee9771 # 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. I'm not actually claiming anywhere that it is the same size. Indeed, I was thinking ahead here. Backporting this to earlier versions of CPython will not be completely trivial, but let's leave it to Cython. # 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. There *is* actually an important reason to limit it: it allows code to make assumptions on what __get__ does. This enables optimizations which wouldn't be possible otherwise. If you cannot be sure what __get__ does, then you cannot optimize obj.method(x) to type(obj).method(obj, x) I see now. Yes, that's reasonable. "if func supports the C call protocol, then func.__set__ must not be implemented." -- also, __delete__ should not be implemented, right?. Indeed. I write Python but I think C API, so for me these are both really tp_descr_set. PyCCall_FASTCALL is not a macro, shouldn't it be named PyCCall_FastCall? What's the convention for that anyway? I assumed that capital letters meant a "really know what you are doing" function which could segfault if used badly. Well, I don't think that's a useful distinction either. This is C; pretty much anything can segfault when used badly. Macros tend to be "fast": Py_TYPE just gets a member of a struct; Py_INCREF just increments a number. METH_NOARGS is just a number. None of them are very dangerous. IMO, PyTuple_GET_ITEM is not uppercase because it's dangerous, but because it just reaches into memory. For me, whether something is a function or macro is just an implementation detail (which can change between Python versions) which should not affect the naming. True. I'm not saying the convention is very strict or useful. # 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_*. I'm fine with that if you insist. However, it would be a silly solution to formally satisfy the "stable ABI" requirement without actually helping. Yes, it's definitely very silly. But that's not a reason to break our promise to the users. After all it's called "stable ABI", not "useful ABI" :) I agree with your other points that I didn't reply to and will make some edits to PEP 580. Thank you! ___ 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/13/2018 07:01 AM, Eric V. Smith wrote: On 9/12/2018 8:33 PM, Victor Stinner wrote: 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 I'm strongly opposed to this. This !t conversion would not be widely applicable enough to be generally useful, and would need to be exposed in the f-string and str.format() documentation, even though 99% of programmers would never need or see it. I discussed this with Eric in-person this morning at the core dev sprints. Eric's understanding is that this is motivated by the fact that Py_TYPE() returns a borrowed reference, and by switching to this !t conversion we could avoid using Py_TYPE() when formatting error messages. My quick thoughts on this: * If Py_TYPE() is a bad API, then it's a bad API and should be replaced. We should have a new version of Py_TYPE() that returns a strong reference. * If we're talking about formatting error messages, we're formatting an exception, which means we're already no longer in performance-sensitive code. So we should use the new API that returns a strong reference. The negligible speed hit of taking the extra reference will be irrelevant. Cheers, //arry/ ___ 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] Request for review
Hi, Can I request a review of https://github.com/python/cpython/pull/6641. It has been open for a few months now. Cheers, Mark. ___ 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?
Le jeu. 13 sept. 2018 à 16:01, Eric V. Smith a écrit :
> > * Add !t conversion to format string
>
> I'm strongly opposed to this. This !t conversion would not be widely
> applicable enough to be generally useful, and would need to be exposed
> in the f-string and str.format() documentation, even though 99% of
> programmers would never need or see it.
(I'm thinking aloud.)
In the Python code base, I found 115 lines using type(obj).__name__
and 228 lines using obj.__class__.__name__.
$ scm.py grep 'type(.*).__name__'|wc -l
115
$ scm.py grep '.__class__.__name__'|wc -l
228
I don't know how to compare these numbers, so I tried to count the
number of f-strings:
$ git grep '[^"%-]\)
x.__class__:
---
Moreover, it's also possible to override the "type" symbol in the
global or local scope:
---
type = id
num = 42
print(f"type(num): {type(num)}")
# Output: "type(num): 139665950357856"
---
One advantage of having a builtin formatter would be to always use
internally the builtin type() function to get the type of an object,
or not use "type()" in the current scope. The second advantage is to
prevent the need of having to decide between type(obj) and
obj.__class__ :-)
> raise TypeError(f"must be str, not {obj!t}")
>
> Should be written as:
> raise TypeError(f"must be str, not {type(obj)}")
f"{type(obj)}" behaves as str(type(obj)), but in practice it uses
repr(type(obj)):
>>> f"{type(42)}"
""
My proposed f"{obj!t}" returns the fully qualified name of the object type:
>>> f"{42!t}"
"int"
Do you want to modify str(type) to return a value different than repr(type)?
Or maybe it's just a typo and you wanted to write f"{type(obj):T}"?
> That said, I think this is a good idea. type.__format__() could also
> understand "#" to specify qualname.
When I discussed with Petr Viktorin, we failed to find an usecase
where __qualname__ was needed. We agreed that we always want the fully
qualified name, not just the qualified name.
> I think "T" is a good idea, but I think you're adding in obj vs
> type(obj) just because of the borrowed reference issue in Py_TYPE().
> That issue is so much larger than string formatting the type of an
> object that it shouldn't be addressed here.
Right, that's a side effect of the discussion on the C API. It seems
like Py_TYPE() has to go in the new C API. Sorry, the rationale is not
written down yet, but Dino convinced me that Py_TYPE() has to go :-)
> > Open question: Should we also add "%t" and "%T" formatters to the str
> > % args operator at the Python level?
>
> No. Again, I think any formatting of type names should not be in a
> widely used interface, (...)
Ok, that's fine with me :-)
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/13/18 14:08, Victor Stinner wrote:
Le jeu. 13 sept. 2018 à 16:01, Eric V. Smith a écrit :
* Add !t conversion to format string
I'm strongly opposed to this. This !t conversion would not be widely
applicable enough to be generally useful, and would need to be exposed
in the f-string and str.format() documentation, even though 99% of
programmers would never need or see it.
(I'm thinking aloud.)
In the Python code base, I found 115 lines using type(obj).__name__
and 228 lines using obj.__class__.__name__.
[...]
"!t" is not a big improvement over ":T" and "type(obj)".
I'm not sure if type(obj) or obj.__class__ should be used, but I can
say that they are different: obj.__class__ can be overriden:
[...]
Moreover, it's also possible to override the "type" symbol in the
global or local scope:
[...]
I don't think either of those are problematic. If you override
`__class__` or `type`, things will behave weirdly, and that's OK.
One advantage of having a builtin formatter would be to always use
internally the builtin type() function to get the type of an object,
or not use "type()" in the current scope. The second advantage is to
prevent the need of having to decide between type(obj) and
obj.__class__ :-)
raise TypeError(f"must be str, not {obj!t}")
Should be written as:
raise TypeError(f"must be str, not {type(obj)}")
[...]
Do you want to modify str(type) to return a value different than repr(type)?
Or maybe it's just a typo and you wanted to write f"{type(obj):T}"?
Yes, AFAIK that was a typo.
I think "T" is a good idea, but I think you're adding in obj vs
type(obj) just because of the borrowed reference issue in Py_TYPE().
That issue is so much larger than string formatting the type of an
object that it shouldn't be addressed here.
Right, that's a side effect of the discussion on the C API. It seems
like Py_TYPE() has to go in the new C API. Sorry, the rationale is not
written down yet, but Dino convinced me that Py_TYPE() has to go :-)
I'll be happy when we get rid of Py_TYPE and get to use moving garbage
collectors... but now is not the time.
The API for "%T" should be "give me the type". The best way to do that
might change in the future.
But at this point, we're bikeshedding. I think all the relevant voices
have been heard.
___
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 9/13/2018 5:52 PM, Petr Viktorin wrote:
On 09/13/18 14:08, Victor Stinner wrote:
Le jeu. 13 sept. 2018 à 16:01, Eric V. Smith a
écrit :
* Add !t conversion to format string
I'm strongly opposed to this. This !t conversion would not be widely
applicable enough to be generally useful, and would need to be exposed
in the f-string and str.format() documentation, even though 99% of
programmers would never need or see it.
(I'm thinking aloud.)
In the Python code base, I found 115 lines using type(obj).__name__
and 228 lines using obj.__class__.__name__.
[...]
"!t" is not a big improvement over ":T" and "type(obj)".
I'm not sure if type(obj) or obj.__class__ should be used, but I can
say that they are different: obj.__class__ can be overriden:
[...]
Moreover, it's also possible to override the "type" symbol in the
global or local scope:
[...]
I don't think either of those are problematic. If you override
`__class__` or `type`, things will behave weirdly, and that's OK.
One advantage of having a builtin formatter would be to always use
internally the builtin type() function to get the type of an object,
or not use "type()" in the current scope. The second advantage is to
prevent the need of having to decide between type(obj) and
obj.__class__ :-)
raise TypeError(f"must be str, not {obj!t}")
Should be written as:
raise TypeError(f"must be str, not {type(obj)}")
[...]
Do you want to modify str(type) to return a value different than
repr(type)?
Or maybe it's just a typo and you wanted to write f"{type(obj):T}"?
Yes, AFAIK that was a typo.
f'{type(obj)}' becomes type(obj).__format__(''), so you can return
something other than __str__ or __repr__ does. It's only by convention
that an object's __format__ returns __str__: it need not do so.
Eric
I think "T" is a good idea, but I think you're adding in obj vs
type(obj) just because of the borrowed reference issue in Py_TYPE().
That issue is so much larger than string formatting the type of an
object that it shouldn't be addressed here.
Right, that's a side effect of the discussion on the C API. It seems
like Py_TYPE() has to go in the new C API. Sorry, the rationale is not
written down yet, but Dino convinced me that Py_TYPE() has to go :-)
I'll be happy when we get rid of Py_TYPE and get to use moving garbage
collectors... but now is not the time.
The API for "%T" should be "give me the type". The best way to do that
might change in the future.
But at this point, we're bikeshedding. I think all the relevant voices
have been heard.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
___
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] We cannot fix all issues: let's close XML security issues (not fix them)
On 06/09/2018 07.18, Victor Stinner wrote: > Hi, > > The Python bug tracker is full of bugs, and sadly we don't have enough > people to take care of all of them. There are 3 open bugs about > security issues in XML and I simply propose to close it: > >https://bugs.python.org/issue17318 >https://bugs.python.org/issue17239 >https://bugs.python.org/issue24238 > > The XML documentation already starts with a red warning explaining the > security limitations of the Python implementation and points to > defusedxml and defusedexpat which are existing and working > counter-measures: > >https://docs.python.org/dev/library/xml.html > > Note: Christian Heimes, author of these 2 packages, told me that these > modules may not work on Python 3.7, he didn't have time to maintain > them recently. Maybe someone might want to help him? > > I suggest to close the 3 Python bugs without doing anything. Are you > ok with that? Keeping the issue open for 3 years doesn't help anyone, > and there is already a security warning in all supported version (I > checked 2.7 and 3.4). > > It seems like XML is getting less popular because of JSON becoming > more popular (even if JSON obviously comes with its own set of > security issues...). It seems like less core developers care about XML > (today than 3 years ago). > > We should just accept that core developers have limited availability > and that documenting security issues is an *acceptable* trade-off. I > don't see any value of keeping these 3 issues open. Hi, during the Python core developer sprint, Steve Dower forced ^H^H^H^H^H^H convinced me into looking into the XML security bugs again. I come with fixes for all issues. However all security fixes require a change of behavior. I strongly believe that the change doesn't affect the majority of users in a negative way. For entity expansion attacks (billion laughs, quadratic blowup), the issue cannot be fixed in a libexpat callback. I decided that it's better to fix the issue in expat directly. libxml2 added limits for entity expansion many years ago, too. I created a patch for libexpat to limit nesting depths, entity length and ratio between XML data and expansion, https://github.com/libexpat/libexpat/pull/220 . The PR is a proof of concept. For the external entity and DTD bug in SAX and pulldom parser, I changed the default setting in PR https://github.com/python/cpython/pull/9217 . When accepted, the parsers no longer load and embed files from local directories or network locations. Regards, Christian ___ 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] PEP 579 and PEP 580: refactoring C functions and methods
2018年9月13日(木) 18:22 Jeroen Demeyer : > On 2018-09-13 02:26, Petr Viktorin wrote: > > > PyCCall_FASTCALL is not a macro, shouldn't it be named PyCCall_FastCall? > > What's the convention for that anyway? I assumed that capital letters > meant a "really know what you are doing" function which could segfault > if used badly. > > For me, whether something is a function or macro is just an > implementation detail (which can change between Python versions) which > should not affect the naming. > https://www.python.org/dev/peps/pep-0007/#naming-conventions All capital name is used for macros. > ___ 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?
Le ven. 14 sept. 2018 à 00:09, Eric V. Smith a écrit :
> f'{type(obj)}' becomes type(obj).__format__(''), so you can return
> something other than __str__ or __repr__ does. It's only by convention
> that an object's __format__ returns __str__: it need not do so.
What's New in Python 3.7 contains:
> object.__format__(x, '') is now equivalent to str(x) rather than
> format(str(self), '').
> (Contributed by Serhiy Storchaka in bpo-28974.)
https://bugs.python.org/issue28974
Oh, I didn't know that a type is free to change this behavior: return
something different than str(obj) if the format spec is an empty
string.
So are you suggesting to change type(obj).__format__('') to return the
fully qualified name instead of repr(type)?
So "%s" % type(obj) would use repr(), but "{}".format(type(obj)) and
f"{type(obj)}" would return the fully qualified name?
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 9/13/2018 8:04 PM, Victor Stinner wrote:
Le ven. 14 sept. 2018 à 00:09, Eric V. Smith a écrit :
f'{type(obj)}' becomes type(obj).__format__(''), so you can return
something other than __str__ or __repr__ does. It's only by convention
that an object's __format__ returns __str__: it need not do so.
What's New in Python 3.7 contains:
object.__format__(x, '') is now equivalent to str(x) rather than
format(str(self), '').
(Contributed by Serhiy Storchaka in bpo-28974.)
https://bugs.python.org/issue28974
Oh, I didn't know that a type is free to change this behavior: return
something different than str(obj) if the format spec is an empty
string.
True! That issue was specific to object.__format__, not any other
classes implementation of __format__.
So are you suggesting to change type(obj).__format__('') to return the
fully qualified name instead of repr(type)?
I'm not suggesting it, I'm saying it's possible. It indeed might be the
most useful behavior.
So "%s" % type(obj) would use repr(), but "{}".format(type(obj)) and
f"{type(obj)}" would return the fully qualified name?
"%s" % type(obj) would use str(), not repr.
You could either:
- keep with convention and have type(obj).__format__('') return
type(obj).__str__(), while type(obj).__format__('#') (or what other char you
want to use) return the qualname;
or
- just have type(obj).__format__('') return the qualname, if that's the more
useful behavior.
Eric
___
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-13, Victor Stinner wrote:
> Right, that's a side effect of the discussion on the C API. It seems
> like Py_TYPE() has to go in the new C API. Sorry, the rationale is not
> written down yet, but Dino convinced me that Py_TYPE() has to go :-)
My understanding is that using Py_TYPE() inside the CPython
internals is okay (i.e. using a borrowed reference). However,
extension modules would preferrably not use APIs that give back
borrowed references. A clean API redesign would remove all of
those.
So, what are extension modules supposed to do? We want to give them
an easy to use API. If we give them %t that takes an object and
internally does the Py_TYPE() call, they have a simple way to do the
right thing.
E.g.
PyErr_Format(PyExc_TypeError,
"\"%s\" must be string, not %.200s", name,
src->ob_type->tp_name);
becomes
PyErr_Format(PyExc_TypeError,
"\"%s\" must be string, not %t", name, src);
This kind of code occurs often in extension modules. If you make
them get a strong reference to the type, they have to remember to
decref it. It's not a huge deal but is a bit harder to use. I like
the proposal to provide both %t and %T. Our format code is a bit
more complicated but many extension modules get a bit simpler.
That's a win, IMHO.
For the Python side, I don't think you need the % format codes. You
need a idiomatic way of getting the type name. repr() and str() of
the type object is not it. I don't think changing them at this
point is a good idea. So, having a new property would seem the
obvious solution. E.g.
f'"{name}" must be string, not {src.__class__.__qualname__}'
That __qualname__ property will be useful for other things, not just
building type error messages.
___
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] Heap-allocated StructSequences
On 2018-09-04, Eddie Elizondo wrote: > Solution: > > * Fix the implementation of PyStructSequence_NewType: > > The best solution would be to fix the implementation of this > function. This can easily be done by dynamically creating a > PyType_Spec and calling PyType_FromSpec Hello Eddie, Thank you for spending time to look into this. Without studying the details of your patch, your approach sounds correct to me. I think we should be allocating types from the heap and use PyType_FromSpec. Having static type definitions living in the data segment cause too many issues. We have to assess how 3rd party extension modules would be affected by this change. Unless it is too hard to do, they should still compile (perhaps with warnings) after your fix. Do you know if that's the case? Looking at your changes to structseq.c, I can't tell easily. In any case, this should go into Victor's pythoncapi fork. That fork includes all the C-API cleanup we are hoping to make to CPython (assuming we can figure out the backwards and forwards compatibility issues). Here is the project site: https://pythoncapi.readthedocs.io Regards, Neil ___ 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
