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

[Tim Peters]

[Tim]
>
> > Note that transforming
> >
> > {EXPR!d:FMT}
> >
> > into
> >
> > EXPR={repr(EXPR):FMT}
> >
> > is actually slightly more involved than transforming it into
> >
> > EXPR={EXPR:FMT}
> >
> > so I don't buy the argument that the original idea is simpler.  More
> > magical and less useful, yes ;-)
>

[Eric V. Smith]

> Actually, my proposal is to apply FMT to the entire result of

EXPR={repr(EXPR)}, not just the repr(EXPR) part. I'm not sure either is
> particularly useful.
>

So the actual transformation is from

{EXPR!d:FMT}

to

{"EXPR=" + repr(EXPR):FMT}

I expect I'll barely use "!d" at all if the format doesn't apply to the
result of EXPR, so I have no non-contrived ;-) opinion about that.

BTW, I checked, and I've never used !r, !s, or !a.  So the idea that the
format could apply to a string - when EXPR itself doesn't evaluate to a
string - is simply foreign to me.  I suppose it's natural to people who do
use ![rsa] all the time - if such people exist ;-)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Marcus Harnisch]

On 10/04/2018 06:51 PM, Antoine Pitrou wrote:

I don't know.  Realistically, any decent distributor of Python
should include those optional modules, and I don't remember
encountering a Python that doesn't has them.
What is the point, then, of making these packages optional in the first 
place? Shouldn't by that logic a missing dependency rather trigger a 
build failure /unless/ someone enables a certain switch (e.g. 
‘--without-xz’), e.g. for special-purpose distribution.



Adding a note saying otherwise in the docs may pointlessly scare users away.
Possibly. But not saying anything isn't the best alternative under these 
circumstances.


Thanks,
Marcus
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 output to the correct stream, whatever it should be.

Rhodri:  Thank you for your contribution. Are you saying that because
the developer can write
print(a, b, c, file=sys.stderr)
there's not a problem to solve here?
-- 
Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 output. In other words,
something like


import sys
sys.stddebug = sys.stderr
debug = lambda *argv, **kwargs: print(*argv, file=sys.stddebug, flush=True, 
**kwargs)


Note: Need to use current value of sys.stddebug, so can't use functools.partial.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/



Or write your debug output to stderr?

--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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

>>> import sys
>>> sys.stddebug = sys.stderr
>>> debug = lambda *argv, **kwargs: print(*argv, file=sys.stddebug, flush=True, 
>>> **kwargs)

Note: Need to use current value of sys.stddebug, so can't use functools.partial.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Antoine Pitrou]

On Thu, 4 Oct 2018 08:32:55 +1000
Steven D'Aprano  wrote:
> 
> > 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 don't know.  Realistically, any decent distributor of Python
should include those optional modules, and I don't remember
encountering a Python that doesn't has them.  Adding a note saying
otherwise in the docs may pointlessly scare users away.

Regards

Antoine.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Marcus Harnisch]

Hi Steven

On 10/04/2018 12:32 AM, Steven D'Aprano wrote:

On Wed, Oct 03, 2018 at 10:29:45PM +0200, Marcus Harnisch wrote:

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
Python. Since I suspect that there are other optional stdlib modules,
this made me think whether the message in those cases should look a
little more polished. Perhaps installing a stub module that prints some
informative text before raising the relevant exception or similar.

This sounds to me like something that the various Python distributors
could do, e.g. Activestate, the Linux distros, etc. Especially since
they're the ones compiling Python, they can control whether or not XY is
supplied or not.
I'd argue that it is Python that creates the dependency and is therefore 
responsible to handle this gracefully. But, I guess having this 
documented first is the most important step before discussing further 
measures.

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.

Done. https://bugs.python.org/issue34895

Thanks,
Marcus

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 discuss this particular topic right now, please
start a new discussion thread for that purpose.

Later today, I'll be posting another problem and proposed solution to
this thread, and would like your help on that.

Many thanks

Jonathan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 defining specs, not there isn't a difference between those things.

So in terms of X there is no difference in Y. No kidding. Which is why I said 
so. Repeatedly. 

>  Changing the language spec is not a thing to do lightly regardless of how 
> many implementations happen to do what you already want.  

Where do you think I'm taking it lightly? I'm taking changing all python 
implementations seriously. That has non-zero weight to me. Do you and Chris 
think that changing the implementations of all python implementations and the 
complexity of that change is totally irrelevant to all discussions? I sure hope 
not! 

Changing the spec AND all implementations is pretty much by definition a bigger 
change and should be taken more seriously than only the spec. I don't take 
changing the spec lightly because I think changing the spec AND all 
implementation is MORE. 

I can't believe I'm arguing that 1 + 1 > 1 but here we are. 

I would hope you could drop this idea that I'm taking things "lightly" whatever 
that means. If I were taking it lightly I would have already submitted a PEP. 

> While gather evidence that the chaos your change will cause is minimal is a 
> good thing, it doesn't actually lower the bar for getting a language spec 
> change through.

Why do you repeat that? No one is saying the opposite. I'm saying the facts 
lowers the bar for IMPLEMENTATION. Because it's literally zero. That is totally 
orthogonal to the bar for getting a spec change through of course. Which I have 
already conceded like ten times now. 

How many times do I have to concede this point before you stop saying I need to 
concede it? Do I need to write it with my own blood on parchment or something?

> Think of it this way: you are proposing to break a promise.  Even if it's 
> only a little thing and you're fairly sure everyone will forgive you, that's 
> still not something you should ever want to get comfortable doing.

Every new thread on this mailing list does this. This is the entire point of 
this list. And I've conceded this point so you're just beating a dead horse.

/ Anders 
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mikhail V]

On Wed, Oct 3, 2018 at 3:28 AM 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!), followed by an
> equal sign, followed by the repr of the value of the expression. So:
> [...]
> The mnemonic is !d for “debugging”. I’d wanted to use !=, because
> there’s an equal sign involved in the result, but = is the one character
> that can’t be used after ! (it’s “not equal” in expressions, and
> f-strings look specifically for that case). I also mentioned !!, but I
> think I prefer !d as being less confusing.
>
> This would be used in debugging print statements, that currently end up
> looking like:
>
> print(f'value={value!r}')
>
> and would now be:
>
> print(f'{value!d}')
>
> There have been discussions about ways to specify str() vs. repr(),
> using characters other than '=', adding spaces, etc. But they all end up
> over-complicating what should be a simple tool, not a Swiss Army knife.
>
> Thoughts?
>
> Eric

I think the feature is useful to avoid re-typing the expressions.
But still, the syntax is a bit obscure, and the feature
is very limited (can't construct anything but "x=x").
That makes me personally less enthusiastic about using it instead
of the common: f" x = {x}". (yes I use spaces around = most of
the time and probably only spaces for table-like output)

Did you think about more general syntax for repetitions?
If there would be a way to repeat entries, one could do similar output
without much extra typing.

E.g. an asterisk for "same expression" ?

price = 10
s = f"{price} {*}"# 10 10

And then using say {expr !} would print _only_ the expression string.
So with e.g. some variable:

variable = 13.18654937
f"{variable !} = {*:.4f}  {*:.2f}  {*:.0f}"
prints:
variable = 13.1865  13.19  13

Something like that. It is more complex implementation, etc,
but has better, verbose appearance Imo and not so limited.
And custom formatting is important to achieve a readable output.


Mikhail
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 topic.


In terms of defining specs, not there isn't a difference between those 
things.  Changing the language spec is not a thing to do lightly 
regardless of how many implementations happen to do what you already 
want.  While gather evidence that the chaos your change will cause is 
minimal is a good thing, it doesn't actually lower the bar for getting a 
language spec change through.


Think of it this way: you are proposing to break a promise.  Even if 
it's only a little thing and you're fairly sure everyone will forgive 
you, that's still not something you should ever want to get comfortable 
doing.



--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 that this change has very little cost, but it should not be 
>> dismissed.
>> 
>> 
>> It works in:
>> 
>> Python 1
>> Python 2
>> Python 3
>> PyPy 6
>> IronPython
>> Jython
>> micropython
>> 
>> Are there more I should try?
> 
> I've no idea what you actually tried or what actually worked, since
> you haven't shown your code.

Please take a deep breath. The question was not directed at you and I just 
answered a clear and simply stated question. 

All the examples cited, including the one you link to below work. No need to 
get angry about this. If you are upset if I discuss implementation details 
don't reply. This is all I'm doing at this point. 

> 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. 

> This IS a
> language change

Yes I agree. I have said so many times. 

> , and it makes no difference how many implementations
> are lax enough to permit it currently.

Sure it does. See above. 

> You can show millions,
> billions, trillions of examples that support your assumption, but that
> doesn't make any difference - the assumption is false as soon as there
> is a single counter-example, 

...which there isn't. But that's irrelevant. We both agree it's irrelevant. 

> or as soon as the specification is shown
> to *permit* a counter-example.

Maybe. But I haven't argued that this implementation detail is already in the 
spec have I? I have just argued that it's easy to IMPLEMENT because it is in 
fact already implemented in all existing pythons. 

I don't see why this is such a hard concept for you to grasp. 

Yes I know it would be a change to the spec. I have conceded this point MANY 
TIMES. You don't need to argue that point, you've already won it. By walk over 
even because I never argued against it. 

Can we drop this now? Your point has been made. 

/ Anders
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 a language change 
> seemed too broad to me.
> It may be that this change has very little cost, but it should not be 
> dismissed.
>
>
> It works in:
>
> Python 1
> Python 2
> Python 3
> PyPy 6
> IronPython
> Jython
> micropython
>
> Are there more I should try?

I've no idea what you actually tried or what actually worked, since
you haven't shown your code. However, it doesn't matter. This IS a
language change, and it makes no difference how many implementations
are lax enough to permit it currently.

Citation: https://mail.python.org/pipermail/python-dev/2018-October/155437.html

It's just like a program assuming that there will always be a user
with UID 0, or assuming that every human being has a name that
consists of a given name and a family name, or assuming that data sent
across the internet will arrive unchanged. You can show millions,
billions, trillions of examples that support your assumption, but that
doesn't make any difference - the assumption is false as soon as there
is a single counter-example, or as soon as the specification is shown
to *permit* a counter-example.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

On 10/3/2018 8:47 PM, Tim Peters wrote:

Note that transforming

    {EXPR!d:FMT}

into

    EXPR={repr(EXPR):FMT}

is actually slightly more involved than transforming it into

    EXPR={EXPR:FMT}

so I don't buy the argument that the original idea is simpler.  More 
magical and less useful, yes ;-)


Actually, my proposal is to apply FMT to the entire result of 
EXPR={repr(EXPR)}, not just the repr(EXPR) part. I'm not sure either is 
particularly useful.


Eric
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 that this change has very little cost, but it should not be 
> dismissed.

It works in: 

Python 1
Python 2
Python 3
PyPy 6
IronPython
Jython
micropython

Are there more I should try?

I highly recommend https://tio.run/  for trying this out. 
It's pretty cool! It doesn't have micropython but it has the others.

/ Anders___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[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 value. 
I've never worked with that and it sounds really memory intensive, but 
the examples were quite interesting.


When you are in a loop, you want to break at a certain iteration.
When you are in a recursive function, you want to stop at the right point.
etc.

Cheers,
Hans

On 03/10/18 16:51, 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.

We already have a problem and possible solution, provided by Eric
Smith and Larry Hastings.


TITLE: f-string "debug" conversion
URL: https://mail.python.org/pipermail/python-ideas/2018-October/053956.html
PROBLEM
Writing
 print('value = ', value)
is tedious, particularly for more complicated expressions, such as
 print('big_array[5:20] =', big_array[5:20])

POSSIBLE SOLUTION

For f-strings, we add a !d conversion operator, which produces the
text of an expression followed by its value. Thus, the two previous
examples can be written more concisely as
 print(f'{value !d}')
 print(f'{big_array[5:20] !d}')


I suggest for the moment that we just gather problem-solution pairs,
much as above. I think they'll be between 5 and 15 such pairs. I'll
post one to the current discussion thread in an hour or so.

And that after about a week, we move to discussing what we have.
Finally, many thanks to Eric and Larry for their useful contribution
to the important problem of debugging.



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/