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
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
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
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
> 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
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
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
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
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
>>>
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
> [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
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
>> 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
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
> 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
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
>> 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
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
>
> 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
>> 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
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
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:
>
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
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
>> 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
> 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
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
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
>> 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
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
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
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
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] =',
>> 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
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:
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():
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
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
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
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
40 matches
Mail list logo
