Re: [Python-ideas] f-string "debug" conversion

On Tue, Oct 02, 2018 at 08:27:03PM -0400, Eric V. Smith wrote: > Here’s the idea: for f-strings, we add a !d conversion operator, which > is superficially similar to !s, !r, and !a. The meaning of !d is: > produce the text of the expression (not its value!), I SO WANT THIS AS A GENERAL FEATURE,

Re: [Python-ideas] f-string "debug" conversion

>> Here’s the idea: for f-strings, we add a !d conversion operator, which >> is superficially similar to !s, !r, and !a. The meaning of !d is: >> produce the text of the expression (not its value!), > > I SO WANT THIS AS A GENERAL FEATURE, not just for f-strings, it hurts. > > Actually what I

Re: [Python-ideas] f-string "debug" conversion

On Wed, Oct 03, 2018 at 06:57:19AM +0200, Anders Hovmöller wrote: > debug(next=value+1) > > Still shorter than the proposed syntax Are we trying to emulate Perl now? *wink* > and much more readable. So you say. To me that looks like a regular function call, which calls an ordinary functio

Re: [Python-ideas] f-string "debug" conversion

On Wed, Oct 3, 2018 at 6:06 PM Steven D'Aprano wrote: > > On Wed, Oct 03, 2018 at 06:57:19AM +0200, Anders Hovmöller wrote: > > > debug(next=value+1) > > > > Still shorter than the proposed syntax > > Are we trying to emulate Perl now? *wink* > > > > and much more readable. > > So you say. > > To

Re: [Python-ideas] f-string "debug" conversion

On Wed, Oct 3, 2018 at 5:54 PM Steven D'Aprano wrote: > I'm not so sure that it only makes sense for named arguments. I think it > works for arbitrary expressions too: > > f'{len("NOBODY expects the Spanish Inquisition!")!d}' > > ought to return > > 'len("NOBODY expects the Spanish Inquisition!")=

Re: [Python-ideas] f-string "debug" conversion

>> and much more readable. > > So you say. > > To me that looks like a regular function call, which calls an ordinary > function "debug" and takes a simple keyword argument next with value > "value+1". That was what it was. That was not intended to be about magic, that was the normal case w

Re: [Python-ideas] f-string "debug" conversion

On Wed, Oct 3, 2018 at 6:49 PM Anders Hovmöller wrote: > > I don't really think accidents of implementation are different from hard > requirements in Python, as it applies to alternative implementations. In > practice if it deviates from CPython then it's broken. There is no language > spec, th

Re: [Python-ideas] f-string "debug" conversion

>> I don't really think accidents of implementation are different from hard >> requirements in Python, as it applies to alternative implementations. In >> practice if it deviates from CPython then it's broken. There is no language >> spec, there is only CPython. This has been the experience an

Re: [Python-ideas] f-string "debug" conversion

On Wed, Oct 3, 2018 at 7:09 PM Anders Hovmöller wrote: > > > >> I don't really think accidents of implementation are different from hard > >> requirements in Python, as it applies to alternative implementations. In > >> practice if it deviates from CPython then it's broken. There is no > >> lan

Re: [Python-ideas] f-string "debug" conversion

As a user I would be really pleased with the change proposed, as I use extensively use f-string in my logging (the fact that I have to evaluate the string whatever the logger level is is not a performance hit for my application), and usually the most readable logging format is something akin to f"i

Re: [Python-ideas] f-string "debug" conversion

Hi Eric Summary: This email is mainly about process. One discussion thread or several. I think the decision is yours. You wrote suggesting an enhancement for debugging: > Here’s the idea: for f-strings, we add a !d conversion operator, which > is superficially similar to !s, !r, and !a. The mean

Re: [Python-ideas] f-string "debug" conversion

> The present discussion thread is spreading into other areas, such as > what constitutes the Python language specification. I let myself get side tracked. This will be my last mail discussing that off topic thread. Sorry about that. > I'd like to > contribute to a broader discussion, of how w

Re: [Python-ideas] f-string "debug" conversion

On Wed, Oct 3, 2018 at 7:30 PM Jonathan Fine wrote: > Here's my personal opinion, which does not count for much. I like the > output and ease of use. I have doubts about the implementation, and > how it might work with other things. And also, I'd like the change to > go through the PEP process. A

Re: [Python-ideas] f-string "debug" conversion

On Wed, Oct 03, 2018 at 10:48:31AM +0200, Anders Hovmöller wrote: > > >> and much more readable. > > > > So you say. > > > > To me that looks like a regular function call, which calls an ordinary > > function "debug" and takes a simple keyword argument next with value > > "value+1". > > That

Re: [Python-ideas] f-string "debug" conversion

On 10/3/2018 3:54 AM, Steven D'Aprano wrote: On Tue, Oct 02, 2018 at 08:27:03PM -0400, Eric V. Smith wrote: Here’s the idea: for f-strings, we add a !d conversion operator, which is superficially similar to !s, !r, and !a. The meaning of !d is: produce the text of the expression (not its value!

Re: [Python-ideas] f-string "debug" conversion

On 10/3/2018 5:29 AM, Jonathan Fine wrote: Hi Eric Summary: This email is mainly about process. One discussion thread or several. I think the decision is yours. You wrote suggesting an enhancement for debugging: Here’s the idea: for f-strings, we add a !d conversion operator, which is superfi

Re: [Python-ideas] f-string "debug" conversion

On 10/3/2018 1:40 AM, Nathaniel Smith wrote: On Tue, Oct 2, 2018 at 8:44 PM, David Teresi > wrote: > print(f'{value!d}') is a lot of symbols and boilerplate to type out just for > a debugging statement that will be deleted later. Especially now that > breakpoint() e

Re: [Python-ideas] f-string "debug" conversion

On 10/3/2018 12:23 AM, Tim Peters wrote: [Eric V. Smith mailto:e...@trueblade.com>>] Here’s the idea: for f-strings, we add a !d conversion operator, which is superficially similar to !s, !r, and !a. The meaning of !d is: produce the text of the expression (not its value!), followed

Re: [Python-ideas] f-string "debug" conversion

On Wed, 3 Oct 2018 at 11:45, Eric V. Smith wrote: > On 10/3/2018 3:54 AM, Steven D'Aprano wrote: > > On Tue, Oct 02, 2018 at 08:27:03PM -0400, Eric V. Smith wrote: > > > >> Here’s the idea: for f-strings, we add a !d conversion operator, which > >> is superficially similar to !s, !r, and !a. The

[Python-ideas] Debugging: some problems and possible solutions

This thread is about debugging. I suggest we start by collecting problems and possible solutions. And that after about a week of that, we start discussing what we've gathered. We already have a problem and possible solution, provided by Eric Smith and Larry Hastings. TITLE: f-string "debug" conv

Re: [Python-ideas] Debugging: some problems and possible solutions

TITLE: Saving and sharing debug code PROBLEM: Sometimes debug-only code should be saved and shared. For example, one person's code written to solve a bug might be needed a second time, by someone else. Or perhaps the same person, again. This is particularly likely when the bug is difficult or stubb

Re: [Python-ideas] Debugging: some problems and possible solutions

On Thu, Oct 4, 2018 at 12:52 AM Jonathan Fine wrote: > > This thread is about debugging. I suggest we start by collecting > problems and possible solutions. And that after about a week of that, > we start discussing what we've gathered. > Why not just discuss each proposal on its own merits, inde

Re: [Python-ideas] PEPs: Theory of operation [was: Moving to another forum system ...]

On Saturday, September 22, 2018, Wes Turner wrote: > Here are links to the Apache governance docs: > > https://www.apache.org/foundation/governance/#technical > > https://www.apache.org/foundation/governance/pmcs.html > > Which are the PSF docs for these exact same processes for open source > gov

Re: [Python-ideas] Debugging: some problems and possible solutions

On Thu, Oct 4, 2018 at 1:30 AM Jonathan Fine wrote: > > Chris Angelico wrote: > > > Why not just discuss each proposal on its own merits, independently of > > any other proposals? Do they interact with each other? > > Good question. I think they will interact. Not in terms of > implementation, but

Re: [Python-ideas] Debugging: some problems and possible solutions

Chris Angelico wrote: > Why not just discuss each proposal on its own merits, independently of > any other proposals? Do they interact with each other? Good question. I think they will interact. Not in terms of implementation, but in terms of benefit. To quote the Zen of Python: > There should b

Re: [Python-ideas] Debugging: some problems and possible solutions

TITLE: output debug information easily and quickly POSSIBLE SOLUTION Short form of keyword arguments where foo(=a, =1+bar) Is expanded at compile time to foo(**{'a': a, '1+bar': 1+bar}) Then we can just create a normal debug function: def debug_print(**vars): for k, v in vars.items():

Re: [Python-ideas] PEPs: Theory of operation [was: Moving to another forum system ...]

re: Updating the BDFL-Delegate policy (in PEP 1) On Wednesday, October 3, 2018, Wes Turner wrote: > > > On Saturday, September 22, 2018, Wes Turner wrote: > >> [...] >> >> https://devguide.python.org/#contributing >> >> https://devguide.python.org/experts/ >> - is there a different BDFL-delegat

Re: [Python-ideas] PEPs: Theory of operation [was: Moving to another forum system ...]

On 2018-10-03 17:56, Wes Turner wrote: The phrase "core developers and the BDFL" is where some sort of alternate quorum/majority policy would need to be specified if this is a contentious issue in practice? The whole point of the process described in PEP 8000 is to make this more precise. The

Re: [Python-ideas] Debugging: some problems and possible solutions

On Wed, Oct 3, 2018 at 8:42 AM Anders Hovmöller wrote: > foo(=a, =1+bar) Unfortunately, that won't help with Jonathan's inital example expression "big_array[5:20]" as it's not a valid keyword. ___ Python-ideas mailing list Python-ideas@python.org https:

Re: [Python-ideas] Debugging: some problems and possible solutions

>> foo(=a, =1+bar) > > Unfortunately, that won't help with Jonathan's inital example > expression "big_array[5:20]" as it's not a valid keyword. I didn't understand that. The example you are referring to is print('big_array[5:20] =', big_array[5:20]) Right? Nothing is a keyword in that exampl

Re: [Python-ideas] Debugging: some problems and possible solutions

On Wed, Oct 3, 2018 at 9:29 AM Anders Hovmöller wrote: >>> foo(=a, =1+bar) > >> Unfortunately, that won't help with Jonathan's inital example >> expression "big_array[5:20]" as it's not a valid keyword. > > I didn't understand that. The example you are referring to is > print('big_array[5:20] =',

Re: [Python-ideas] Debugging: some problems and possible solutions

foo(=a, =1+bar) >> >>> Unfortunately, that won't help with Jonathan's inital example >>> expression "big_array[5:20]" as it's not a valid keyword. >> >> I didn't understand that. The example you are referring to is >> print('big_array[5:20] =', big_array[5:20]) >> >> Nothing is a keyword

Re: [Python-ideas] Debugging: some problems and possible solutions

On Thu, Oct 4, 2018 at 2:30 AM Anders Hovmöller wrote: > > Nothing is a keyword in that example or in my example. My suggestion is that > we could do: > > my_func(=big_array[5:20]) > > And it would be compile time transformed into > > my_func(**{'big_array[5:20]': big_array[5:20]}) > > and then m

Re: [Python-ideas] Debugging: some problems and possible solutions

Anders Hovmöller suggested > Short form of keyword arguments where > foo(=a, =1+bar) > Is expanded at compile time to > foo(**{'a': a, '1+bar': 1+bar}) Chris Angelico wrote: > That is not guaranteed to work. In another thread it was pointed out > that this is merely a CPython implementation detail

[Python-ideas] Dictionary initialization to capture syntax and value (was Re: Debugging: some problems and possible solutions)

On Thu, Oct 4, 2018 at 4:12 AM Jonathan Fine wrote: > > Anders Hovmöller suggested > > Short form of keyword arguments where > > foo(=a, =1+bar) > > Is expanded at compile time to > > foo(**{'a': a, '1+bar': 1+bar}) > > Chris Angelico wrote: > > That is not guaranteed to work. In another thread it

Re: [Python-ideas] Dictionary initialization to capture syntax and value (was Re: Debugging: some problems and possible solutions)

> Spun off as a new thread because this isn't really specific to debugging. Thank you for starting a new thread, to discuss this idea. -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ide

Re: [Python-ideas] Debugging: some problems and possible solutions

>> It's a very simple textual transformation. >> > > That is not guaranteed to work. In another thread it was pointed out > that this is merely a CPython implementation detail, NOT a language > feature. Pedantry. Ok. Let's be pedantic: it's a simple textual transformation AND a promotion of a

Re: [Python-ideas] Debugging: some problems and possible solutions

On Thu, Oct 4, 2018 at 4:36 AM Anders Hovmöller wrote: > > > >> It's a very simple textual transformation. > >> > > > > That is not guaranteed to work. In another thread it was pointed out > > that this is merely a CPython implementation detail, NOT a language > > feature. > > Pedantry. Ok. Let's

Re: [Python-ideas] Debugging: some problems and possible solutions

On Thu, Oct 4, 2018 at 4:38 AM Chris Angelico wrote: > > On Thu, Oct 4, 2018 at 4:36 AM Anders Hovmöller wrote: > > > > > > >> It's a very simple textual transformation. > > >> > > > > > > That is not guaranteed to work. In another thread it was pointed out > > > that this is merely a CPython imp

Re: [Python-ideas] Debugging: some problems and possible solutions

> So how about extending Python so that, for example, >{=(1 + bar), } > is equivalent to >{'1 + bar': 1 + bar, } > > The basic idea is Anders's, recast to avoid Chris's problem. Chris' problem isn't an actual problem though. Its just a few sentences in a PEP. It might be a problem for

Re: [Python-ideas] Debugging: some problems and possible solutions

>> Then I'm strongly -1 on it. Happy? :) > > And In case it's not clear why I said that, btw: It's not mere > pedantry. Good to see you understood yourself why that mail wasn't so good. > By restating your proposal in those terms, you make it far > broader than a simple textual transformatio

Re: [Python-ideas] Debugging: some problems and possible solutions

On Thu, Oct 4, 2018 at 4:54 AM Anders Hovmöller wrote: > > > > >> Then I'm strongly -1 on it. Happy? :) > > > > And In case it's not clear why I said that, btw: It's not mere > > pedantry. > > Good to see you understood yourself why that mail wasn't so good. > > > By restating your proposal in tho

Re: [Python-ideas] Debugging: some problems and possible solutions

Am 03.10.2018 um 20:46 schrieb Anders Hovmöller: Chris' problem isn't an actual problem though. Its just a few sentences in a PEP. It might be a problem for other python implementations but I'm gonna put say 100 dollars on that it's not actually so. Pypy, jython, ir

Re: [Python-ideas] Debugging: some problems and possible solutions

Hi Wolfram You tried >def f(a): > .. print(a) >f(**{"a":2}) > 2 >f(**{"a+1":2}) > Traceback (most recent call last): > File "python", line 1, in > TypeError: f() got an unexpected keyword argument 'a+1' This is exactly what I would have expected. Please consider the following: >

[Python-ideas] Better error messages for missing optional stdlib packages

Hi all When trying to import lzma on one of my machines, I was suprised to get a normal import error like for any other module. According to the docs lzma has been part of stdlib since 3.3. Further digging revealed that the error is due to the fact that xz wasn't compiled in when building Pyt

Re: [Python-ideas] Debugging: some problems and possible solutions

Am 03.10.2018 um 21:52 schrieb Jonathan Fine: def f(a, **kwargs): pass f(a=1, **{'': 2}) f(a=1, **{'def': 2}) So I think Anders proposal works in CPython. I think you forgot the **kwargs in the parameters to f. Ah, yes. Thank you. So it works in CPython 2.7. But I'm curious, does it work

Re: [Python-ideas] Debugging: some problems and possible solutions

>> Imagine if I said something other totally irrelevant and that is bigger >> change indeed. But I didn't. I suggested not a change of CPython or PyPy or >> IronPython but a few sentences in a PEP. I also didn't suggest that it be >> snuck into the same PEP as my proposed syntax changes. I agr

Re: [Python-ideas] Debugging: some problems and possible solutions

> Ah, yes. Thank you. So it works in CPython 2.7. But I'm curious, does it work > in very old versions? My bet is still on. I take paypay. I will not accept python 1 let's say. It's just easier that way. If **kwargs exists they take strings. > I'm not saying that this is important, because l

Re: [Python-ideas] Better error messages for missing optional stdlib packages

I agree with this. These small changes can save hundreds of people an hour each. In the long run, it pays off. On Wednesday, October 3, 2018 at 4:31:08 PM UTC-4, Marcus Harnisch wrote: > > Hi all > > When trying to import lzma on one of my machines, I was suprised to get > a normal import err

Re: [Python-ideas] Better error messages for missing optional stdlib packages

On Wed, Oct 03, 2018 at 10:29:45PM +0200, Marcus Harnisch wrote: > Hi all > > When trying to import lzma on one of my machines, I was suprised to get > a normal import error like for any other module. According to the docs > lzma has been part of stdlib since 3.3. Further digging revealed that

Re: [Python-ideas] Dictionary initialization to capture syntax and value (was Re: Debugging: some problems and possible solutions)

On Thu, Oct 04, 2018 at 04:17:41AM +1000, Chris Angelico wrote: > > {=(1 + bar), } > > is equivalent to > > {'1 + bar': 1 + bar, } What is so special about dicts that this only works there? If we're going to have syntax to capture the source (and AST) of an expression, it ought to work

Re: [Python-ideas] Better error messages for missing optional stdlib packages

>> Also, maybe add a little note in the docs, stating that despite being >> part of stdlib this module might not be available on all systems. > > That should be uncontroversial. Raise an issue on the bug tracker for > that, or a patch on Github. I believe a PR that is more complex than a spel

Re: [Python-ideas] Dictionary initialization to capture syntax and value (was Re: Debugging: some problems and possible solutions)

>>>{=(1 + bar), } >>> is equivalent to >>>{'1 + bar': 1 + bar, } > > What is so special about dicts that this only works there? > > If we're going to have syntax to capture the source (and AST) of an > expression, it ought to work everywhere. And it ought to be callable, > without hav

Re: [Python-ideas] f-string "debug" conversion

On 10/3/2018 7:07 AM, Eric V. Smith wrote: On 10/3/2018 12:23 AM, Tim Peters wrote: [Eric V. Smith mailto:e...@trueblade.com>>]     Here’s the idea: for f-strings, we add a !d conversion operator, which     is superficially similar to !s, !r, and !a. The meaning of !d is:     produce the tex

Re: [Python-ideas] f-string "debug" conversion

[Tim] > >> But what if >> > >> {EXPR!d:FMT} > >> > >> acted like the current > >> > >> EXPR={EXPR:FMT} > >> > >> ? I'd find _that_ useful often. For example, when displaying floats, > >> where the repr is almost never what I want to see. > >> ... [Eric V. Smith ] > After giv

Re: [Python-ideas] f-string "debug" conversion

Gah! You are overthinking it. This idea is only worth it if it's dead simple, and the version that Eric posted to start this thread, where !d uses the repr() of the expression, is the only one simple enough to bother implementing. -- --Guido van Rossum (python.org/~guido)

Re: [Python-ideas] f-string "debug" conversion

[Guido] > Gah! You are overthinking it. This idea is only worth it if it's dead > simple, and the version that Eric posted to start this thread, where !d > uses the repr() of the expression, is the only one simple enough to bother > implementing. > In that case, I have no real use for it, for rea

Re: [Python-ideas] f-string "debug" conversion

On Wed, Oct 3, 2018, 03:55 Eric V. Smith wrote: > > On 10/3/2018 1:40 AM, Nathaniel Smith wrote: > > I think the way I'd do it would be: > > > > Step 1: Take the current "lnotab" that lets us map bytecode offsets -> > > line numbers, and extend it with more detailed information, so that we > > can

Re: [Python-ideas] Debugging: some problems and possible solutions

On Wed, Oct 3, 2018 at 10:48 AM, Chris Angelico wrote: > On Thu, Oct 4, 2018 at 2:30 AM Anders Hovmöller wrote: >> >> Nothing is a keyword in that example or in my example. My suggestion is that >> we could do: >> >> my_func(=big_array[5:20]) >> >> And it would be compile time transformed into >

Re: [Python-ideas] Debugging: some problems and possible solutions

>> That is not guaranteed to work. In another thread it was pointed out >> that this is merely a CPython implementation detail, NOT a language >> feature. > > I'm curious where this is written down. Can you point to the relevant > part of the language spec or pronouncement or whatever it was? I