Re: [Python-Dev] Easier debugging with f-strings
On 5/6/2019 5:39 PM, Eric V. Smith wrote:
Last fall Larry Hastings made a suggestion for adding a way to make
so-called "print-based debugging" easier with f-strings. Basically the
approach is that f-strings would be able to produce the text of the
expression and the value of that expression, without repeating the
expression in the f-sting. No more writing f'foo={foo}, bar={bar}'.
foo and bar should each only be in there once each!
My plan is to commit this change before 3.8b1. If anyone would like to
discuss it at PyCon, I'll be around until about 10:30 am on Tuesday.
I'll be in the CPython sprint room, and I'll be watching bpo, too.
Yes, I'd like this yesterday, please :) Thanks!
___
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] Easier debugging with f-strings
Last fall Larry Hastings made a suggestion for adding a way to make
so-called "print-based debugging" easier with f-strings. Basically the
approach is that f-strings would be able to produce the text of the
expression and the value of that expression, without repeating the
expression in the f-sting. No more writing f'foo={foo}, bar={bar}'. foo
and bar should each only be in there once each!
At PyCon US 2019 I did a lightning talk about this, suggesting the
syntax of !d, so that if foo="Hello", then f"{foo!d}" would produce
"foo='Hello'". That is, it's the text of the expression, followed by an
equal sign, followed by the repr of the expression. I have implemented
this and a PR exists. Arbitrary expressions are allowed. I heard from
core devs and end users after this talk, and all were positive.
After that lightning talk, Larry and I talked about it some more, and
for a number of reasons decided that it would make more sense if the
syntax used an = sign. So we came up with f"{foo=}", which would also
produce "foo='Hello'".
The reasons for the change are:
- Having '=' in the expression is a better mnemonic than !d.
- By not using a conversion starting with !, we can compose = with the
existing ! conversions, !r, !s, and the rarely used !a.
- We can let the user have a little more control of the resulting string.
Another thing I like about this approach over !d is that the patch is
simpler, because there are fewer special cases. And because there are
fewer special cases in the code, I think the proposal is easier to
explain than !d (in particular how it interacts (or doesn't!) with
format specifiers).
There's a good rationale here, along with a PR:
https://bugs.python.org/issue36817.
My plan is to commit this change before 3.8b1. If anyone would like to
discuss it at PyCon, I'll be around until about 10:30 am on Tuesday.
I'll be in the CPython sprint room, and I'll be watching bpo, too.
Eric
___
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 580/590 discussion
On 5/6/19 3:43 AM, Jeroen Demeyer wrote: On 2019-05-06 00:04, Petr Viktorin wrote: - Single bound method class for all kinds of function classes: This would be a cleaner design, yes, but I don't see a pressing need. As PEP 579 says, "this is a compounding issue", not a goal. As I recall, that is the only major reason for CCALL_DEFARG. Just a minor correction here: I guess that you mean CCALL_SELFARG. The flag CCALL_DEFARG is for passing the PyCCallDef* in PEP 580, which is mostly equivalent to passing the callable object in PEP 590. The signature of PEP 580 is func(const PyCCallDef *def, PyObject *self, PyObject *const *args, Py_ssize_t nargs, PyObject *kwnames) And with PEP 590 it is func(PyObject *callable, PyObject *const *args, Py_ssize_t nargs, PyObject *kwnames) with the additional special role for the PY_VECTORCALL_ARGUMENTS_OFFSET bit (which is meant to solve the problem of "self" in a different way). I worded that badly, sorry. From PEP 590's `callable`, the called function can get any of these if it needs to (and if they're stored somewhere). But you can't write generic code would get them from any callable. If we're not going for the "single bound method class" idea, that is OK; `def` & `self` can be implementation details of the callables that need them. ___ 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] Stable ABI or not for PyTypeObject?
PyType_FromSpec() looks like a better approach for ABI compatibility. My notes on types and ABI: https://pythoncapi.readthedocs.io/type_object.html Victor Le lun. 6 mai 2019 à 09:57, Jeroen Demeyer a écrit : > > Hello, > > I have a simple question for which there doesn't seem to be a good > answer: is the layout of PyTypeObject considered to be part of the > stable ABI? > > Officially, the answer is certainly "no" (see PEP 384). > > However, unofficially the answer might be "yes". At least, the last time > that an incompatible change was made to PyTypeObject (adding tp_finalize > in Python 3.4, PEP 442), care was taken not to break the ABI by using > the Py_TPFLAGS_HAVE_FINALIZE flag. > > There is some discussion about this on https://bugs.python.org/issue32388 > > The implementation of PEP 590 is going to make another ABI-breaking > change. So should we add a new Py_TFLAGS_HAVE_... flag for that or not? > > > Jeroen. > ___ > 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/vstinner%40redhat.com -- Night gathers, and now my watch begins. It shall not end until my death. ___ 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] Stable ABI or not for PyTypeObject?
On Mon, 6 May 2019 15:55:03 +0200 Jeroen Demeyer wrote: > Hello, > > I have a simple question for which there doesn't seem to be a good > answer: is the layout of PyTypeObject considered to be part of the > stable ABI? > > Officially, the answer is certainly "no" (see PEP 384). > > However, unofficially the answer might be "yes". At least, the last time > that an incompatible change was made to PyTypeObject (adding tp_finalize > in Python 3.4, PEP 442), care was taken not to break the ABI by using > the Py_TPFLAGS_HAVE_FINALIZE flag. > > There is some discussion about this on https://bugs.python.org/issue32388 The discussion there was more or less conclusive. At the time it was too late to go into 3.7 and then I (and others) forgot about it. We should revive that PR in time for 3.8. Regards Antoine. ___ 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 580/590 discussion
On 5/6/19 4:24 AM, Jeroen Demeyer wrote: Hello Petr, Thanks for your time. I suggest you (or somebody else) to officially reject PEP 580. I'll do that shortly. I hope that you are not taking this personally. PEP 580 is a good design. PEP 590 even says that it's built on your ideas. I start working on reformulating PEP 590, adding some elements from PEP 580. At the same time, I work on the implementation of PEP 590. I want to implement Mark's idea of having a separate wrapper for each old-style calling convention. In the mean time, we can continue the discussion about the details, for example whether to store the flags inside the instance (I don't have an answer for that right now, I'll need to think about it). I'm abandoning per-instance flag proposal. It's an unnecessary complication; per-type flags are fine. Petr, did you discuss with the Steering Council? It would be good to have some kind of pre-approval that PEP 590 and its implementation will be accepted. I want to work on PEP 590, but I'm not the right person to "defend" it (I know that it's worse in some ways than PEP 580). As BDFL-delegate, I'm "pre-approving" PEP 590. I mentioned some details of PEP 590 that still need attention. If there are any more, now's the time to bring them up. And yes, I know that in some ways it's worse than PEP 580. That's what makes it a hard decision. ___ 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] Stable ABI or not for PyTypeObject?
Hello, I have a simple question for which there doesn't seem to be a good answer: is the layout of PyTypeObject considered to be part of the stable ABI? Officially, the answer is certainly "no" (see PEP 384). However, unofficially the answer might be "yes". At least, the last time that an incompatible change was made to PyTypeObject (adding tp_finalize in Python 3.4, PEP 442), care was taken not to break the ABI by using the Py_TPFLAGS_HAVE_FINALIZE flag. There is some discussion about this on https://bugs.python.org/issue32388 The implementation of PEP 590 is going to make another ABI-breaking change. So should we add a new Py_TFLAGS_HAVE_... flag for that or not? Jeroen. ___ 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 580/590 discussion
Hello Petr, Thanks for your time. I suggest you (or somebody else) to officially reject PEP 580. I start working on reformulating PEP 590, adding some elements from PEP 580. At the same time, I work on the implementation of PEP 590. I want to implement Mark's idea of having a separate wrapper for each old-style calling convention. In the mean time, we can continue the discussion about the details, for example whether to store the flags inside the instance (I don't have an answer for that right now, I'll need to think about it). Petr, did you discuss with the Steering Council? It would be good to have some kind of pre-approval that PEP 590 and its implementation will be accepted. I want to work on PEP 590, but I'm not the right person to "defend" it (I know that it's worse in some ways than PEP 580). Jeroen. ___ 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 580/590 discussion
On 2019-05-06 00:04, Petr Viktorin wrote: - Single bound method class for all kinds of function classes: This would be a cleaner design, yes, but I don't see a pressing need. As PEP 579 says, "this is a compounding issue", not a goal. As I recall, that is the only major reason for CCALL_DEFARG. Just a minor correction here: I guess that you mean CCALL_SELFARG. The flag CCALL_DEFARG is for passing the PyCCallDef* in PEP 580, which is mostly equivalent to passing the callable object in PEP 590. The signature of PEP 580 is func(const PyCCallDef *def, PyObject *self, PyObject *const *args, Py_ssize_t nargs, PyObject *kwnames) And with PEP 590 it is func(PyObject *callable, PyObject *const *args, Py_ssize_t nargs, PyObject *kwnames) with the additional special role for the PY_VECTORCALL_ARGUMENTS_OFFSET bit (which is meant to solve the problem of "self" in a different way). ___ 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
