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

2018-10-08 Thread Rhodri James
On 04/10/18 19:10, Jonathan Fine wrote: In response to my problem-solution pair (fixing a typo) TITLE: Debug print() statements cause doctests to fail Rhodri James wrote: Or write your debug output to stderr? Perhaps I've been too concise. If so, I apologise. My proposal is that the system

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

2018-10-07 Thread Stephen J. Turnbull
Samuel Colvin writes: > Python definitely needs a dedicated debug print command. For *commands* (ie, a REPL), you have Pdb already. It's unlikely a *statement* would be accepted, given that print was demoted from a statement to a function. And it's not obvious why a "debug.print()" function ca

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

2018-10-07 Thread Stephen J. Turnbull
Jonathan Fine writes: > I'm thinking of providing a builtin debug() command "Command" doesn't make much sense in this context. I presume you mean "function". > that 'does the right thing' according to the context. And the > context would include the user's preferences. Which might be to use

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

2018-10-06 Thread Jonathan Fine
Samuel Colvin wrote: > Python definitely needs a dedicated debug print command. > I've built python devtools with has such a command: > https://github.com/samuelcolvin/python-devtools > Is this the kind of thing you were thinking about? Thank you for this comment, Samuel. And also very much for

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

2018-10-05 Thread Samuel Colvin
> So I'm suggesting a new built-in debug() function as an easy and > consistent way to write out debugging information. Python definitely needs a dedicated debug print command. Since "debug" is take in 3.7, perhaps "debug.print" would work? I've built python devtools with has such a command: htt

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

2018-10-05 Thread Jonathan Fine
I wrote: > Perhaps I've been too concise. If so, I apologise. My proposal is that > the system be set up so that > debug(a, b, c) > sends output to the correct stream, whatever it should be. See also: https://docs.python.org/3/whatsnew/3.7.html#pep-553-built-in-breakpoint > Python 3.7 includ

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

2018-10-04 Thread Jonathan Fine
In response to my problem-solution pair (fixing a typo) > TITLE: Debug print() statements cause doctests to fail Rhodri James wrote: > Or write your debug output to stderr? Perhaps I've been too concise. If so, I apologise. My proposal is that the system be set up so that debug(a, b, c) sends

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

2018-10-04 Thread Rhodri James
On 04/10/18 18:41, Jonathan Fine wrote: TITLE: PROBLEM: Debug print() statements cause doctests to fail Adding debug print(...) statements to code can cause doctests to fail. This is because both use sys.stdout as the output stream. POSSIBLE SOLUTION: Provide and use a special stream for debug o

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

2018-10-04 Thread Jonathan Fine
TITLE: PROBLEM: Debug print() statements cause doctests to fail Adding debug print(...) statements to code can cause doctests to fail. This is because both use sys.stdout as the output stream. POSSIBLE SOLUTION: Provide and use a special stream for debug output. In other words, something like >>>

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

2018-10-04 Thread Jonathan Fine
Hello all I think we've established enough basic facts for now, about using a non-identifier string as a keyword in a kwargs dictionary. I'd be most grateful if discussion of this particular topic could be suspended for now, to be resumed when it again becomes relevant. If you are keen to discus

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

2018-10-04 Thread Anders Hovmöller
> [I think >> = ChrisA] >>> However, it doesn't matter. >> Of course it matters. It's the difference between changing the spec and >> changing the spec AND some implementation. There is a difference between >> those two things. You might not care but that's another topic. > > In terms of defi

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

2018-10-04 Thread Rhodri James
On 04/10/18 13:27, Anders Hovmöller wrote: [I think >> = ChrisA] However, it doesn't matter. Of course it matters. It's the difference between changing the spec and changing the spec AND some implementation. There is a difference between those two things. You might not care but that's another

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

2018-10-04 Thread Anders Hovmöller
>> Ah, yes. Thank you. So it works in CPython 2.7. But I'm curious, does it >> work in very old versions? >> I'm not saying that this is important, because language changes always are >> for new versions. However, Anders' claim that this not a language change >> seemed too broad to me. >> It m

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

2018-10-04 Thread Chris Angelico
On Thu, Oct 4, 2018 at 6:33 PM Anders Hovmöller wrote: > > > Ah, yes. Thank you. So it works in CPython 2.7. But I'm curious, does it work > in very old versions? > I'm not saying that this is important, because language changes always are > for new versions. However, Anders' claim that this not

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

2018-10-04 Thread Anders Hovmöller
> Ah, yes. Thank you. So it works in CPython 2.7. But I'm curious, does it work > in very old versions? > I'm not saying that this is important, because language changes always are > for new versions. However, Anders' claim that this not a language change > seemed too broad to me. > It may be t

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

2018-10-04 Thread Hans Polak
Good morning, I read about a "time machine" debugger a long time ago. The debugger would collect all the information of all the calls and the programmer can just execute the code without breakpoints. Later, the programmer can follow the evolution of a variable until it reaches an erroneous val

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

2018-10-03 Thread Anders Hovmöller
>> 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

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

2018-10-03 Thread Nathaniel Smith
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

2018-10-03 Thread Anders Hovmöller
> 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] Debugging: some problems and possible solutions

2018-10-03 Thread Anders Hovmöller
>> 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

2018-10-03 Thread Wolfram Hinderer via Python-ideas
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

2018-10-03 Thread Jonathan Fine
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: >

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

2018-10-03 Thread Wolfram Hinderer via Python-ideas
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

2018-10-03 Thread Chris Angelico
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

2018-10-03 Thread Anders Hovmöller
>> 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

2018-10-03 Thread Anders Hovmöller
> 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

2018-10-03 Thread Chris Angelico
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

2018-10-03 Thread Chris Angelico
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

2018-10-03 Thread Anders Hovmöller
>> 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

2018-10-03 Thread Jonathan Fine
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

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

2018-10-03 Thread Chris Angelico
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

2018-10-03 Thread Anders Hovmöller
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

2018-10-03 Thread Michael Selik
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

2018-10-03 Thread Anders Hovmöller
>> 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

2018-10-03 Thread Michael Selik
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

2018-10-03 Thread Anders Hovmöller
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] Debugging: some problems and possible solutions

2018-10-03 Thread Jonathan Fine
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

2018-10-03 Thread Chris Angelico
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

2018-10-03 Thread Chris Angelico
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] Debugging: some problems and possible solutions

2018-10-03 Thread Jonathan Fine
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