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

[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'm going to be charitable here and suggest that Chris is referring to 
something implicit. The spec clearly says that identifiers must be valid keys 
because otherwise normal functions wouldn't work. But that's it. So in Chris' 
view you're probably asking him to prove a negative. The burden of proof would 
lie on those who say otherwise to show how the spec allows arbitrary strings. 
But no one has made such a claim so it's a bit moot. 

/ 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

[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
>>
>> my_func(**{'big_array[5:20]': big_array[5:20]})
>>
>> and then my_func is just a normal function:
>>
>> def my_func(**kwargs):
>>  Whatever
>>
>> 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.

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?

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
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

[Nathaniel Smith]

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 map e.g. a CALL operation to the exact start and end positions of
> > that call expression in the source. This is free at runtime, and would
> > allow more detailed tracebacks (see [1] for an example), and more
> > detailed coverage information. It would definitely take some work to
> > thread the necessary information through the compiler infrastructure,
> > but I think this would be a worthwhile feature even without the debug()
> > use case.
> >
> > Step 2: Add a 'debug' helper function that exploits the detailed
> > information to reconstruct its call, by peeking into the calling frame
> > and finding the source for the call. Of course this would be a strange
> > and ugly thing to do for a regular function, but for a debugging helper
> > it's reasonable. So e.g. if you had the code:
> >
> >total = debug(x) + debug(y / 10)
> >
> > The output might be:
> >
> >debug:myfile.py:10: 'x' is 3
> >debug:myfile.py:10: 'y / 10' is 7
>
> I'm not positive, but isn't this what q does?

The difference is that without "step 1", there's no reliable way to
figure out the value's source text. q does it by grabbing the source
line and making some guesses based on heuristics, but e.g. in the
example here it gets confused and prints:

 0.0s : x) + q(y / 10=3
 0.0s : x) + q(y / 10=7

So you can think of this idea as (1) make it possible to implement a
reliable version of q, (2) add an built-in implementation.

-n
___
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

[Tim Peters]

[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 reasons already explained (I
rarely want the repr, and already have lots of code that tediously repeats
the

EXPR {EXPR:FMT}

pattern inside f-strings).  Even for displaying integers, where you might
_assume_ I'd be happy with the repr, I'm often not:

print(f"nballs {nballs:,} into nbins {nbins:,}")

is one I just happened to write today.  Without comma formatting, the
output is much harder to read.

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 ;-)
___
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

[Guido van Rossum]

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)
___
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

[Tim Peters]

[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 giving this some more thought, the problem with this approach is
> that there's no way to get the repr of the object, which for debugging
> can be pretty useful (think strings).


Sure there is:

f"{repr(var)!d"}

would expand to, as a matter of course (nothing special about it):

f"{repr(var)={repr(var)}"

which would yield, e.g.,

repr(var)=`a\n'

Special shortcuts for calling `repr()` went out of style when Guido got rid
of that meaning for the backtick symbol ;-)

Remember, by default
> object.__format__ calls object.__str__.
>

Which - since there's already a related default - makes it a Dubious Idea
to make some other spelling use a different default.



> I guess we could get around this by combining !d and !r and assigning
> some meaning to that, which I'd rather not do.
>
> Or, this occurred to me right before hitting "send": if there's no
> format spec, use repr(expr). If there is one (even if it's zero-length),
> use format(expr, spec). I'll have to think on that for a while. Maybe
> there's too much voodoo going on there.
>

 The alternative:  if I want repr,(which I usually don't), make me call
"repr()" (which I don't mind at all).

If there must be a shortcut, "!dr" or "!rd" are at least cryptically
explicit, and

{EXPR!dr}

would expand to

EXPR={repr(EXPR)}
___
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 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 text of the expression (not its value!), followed by an
    equal sign, followed by the repr of the value of the expression.
...

    The result is a string, so if you really wanted to, you could use a
    string formatting spec. So:

    print(f'*{value!d:^20}*'

    would produce:

    *      value=10      *

    Although I don’t think that would be very useful in general.


Me neither ;-)  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 repe is almost never what I want to see.


 >>> f"math.pi={math.pi:.2f}"
'math.pi=3.14'

I have plenty of code already embedding stuff of the form

     EXPR {EXPR:FMT}

and don't really care whether there's a space or an "=" between the 
chunks.  "!d" could act like a macro-expansion operator automating a 
mechanical transformation inside the f-string.  Then I could read "!d" 
as "duplicate" instead of as "debug" ;-)


That's a very interesting idea. It breaks the expectation (which might 
be mine alone!) that the format spec is used on the result of the 
conversion specifier (!s, !r). But maybe that's okay. It does seem 
generally more useful than the format spec being used on the repr of the 
evaluated expression.


After giving this some more thought, the problem with this approach is 
that there's no way to get the repr of the object, which for debugging 
can be pretty useful (think strings). Remember, by default 
object.__format__ calls object.__str__.


I guess we could get around this by combining !d and !r and assigning 
some meaning to that, which I'd rather not do.


Or, this occurred to me right before hitting "send": if there's no 
format spec, use repr(expr). If there is one (even if it's zero-length), 
use format(expr, spec). I'll have to think on that for a while. Maybe 
there's too much voodoo going on there.


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] Dictionary initialization to capture syntax and value (was Re: Debugging: some problems and possible solutions)

[Anders Hovmöller]

>>>{=(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 having to call eval() on the source, which is slow.

So... what are you thinking? We store the AST in a way that can be inspected by 
the inspect module? Seems a bit vague how the API would look. Would you look at 
the stack and traverse it and the frames contain detailed information on where 
a function call originated in the AST? 

That's how I interpret the "works everywhere" idea. It seems pretty complex! I 
hope you have a simpler idea. 

On a related note: any access of the AST will be annoying to use if the 
standard library doesn't have an unparse feature, and if it does, it'll be 
slightly annoying if all formatting and comments are thrown away like the 
current AST does. 

/ 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] Better error messages for missing optional stdlib packages

[Anders Hovmöller]

>> 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 spelling fix needs a bug track 
number. At least that's what the PR submit form lead me to believe when I 
submitted a minor fix last week. 

/ 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] Dictionary initialization to capture syntax and value (was Re: Debugging: some problems and possible solutions)

[Steven D'Aprano]

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 everywhere. And it ought to be callable, 
without having to call eval() on the source, which is slow.



-- 
Steve
___
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

[Steven D'Aprano]

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

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



-- 
Steve
___
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?

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 language changes always are 
> for new versions. However, Anders' claim that this not a language change 
> seemed too broad to me.

Not what I meant. I meant it's not a change to any python implementation. It 
might be a change to promote an implementation detail to the spec as pointed 
out by Chris.

> It may be that this change has very little cost, but it should not be 
> dismissed.

I wasn't dismissing it. I just didn't think it was yet time to bring it up. We 
were still discussing larger themes. 

But if we do have to bring it up: It has zero technical cost in actuality right 
now but might not in the future have zero cost. It's the same argument against 
the guaranteed order of dicts in 3.7: it might have a cost in the future. 

/ 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

[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 agree that would be 
>> bad. It should obviously be a separate PEP.
>> 
> 
> I'm not sure what you're calling irrelevant here. But sure. If you
> want to propose that, propose it. Start a new thread in which you
> propose that, as a language feature, kwargs are allowed to be invalid
> variable names.

But wouldn't it make sense to have a motivating example? Like the one we're 
discussing? Not just suggest it out of the blue?

> You're proposing a change to the language specification,
> and that's not something to just gloss over.

Many people are suggesting language spec changes in this thread and quite a few 
others. This is the forum for it. 

> When PEP 572 started proposing changes to other semantics than just
> assignment expressions, there was a lot of pushback because that was
> seen as an independent proposal (even though it was fairly tightly
> bound to the assignment expressions themselves, in that it'd be
> extremely hard to observe the difference else). What you're proposing
> here is, similarly, a completely independent proposal, and not all
> that tightly bound.

Sure. But I'm only proposing it in the "what if?" way. It's a discussion to see 
what other solutions exists for the problem that the thread started discussing. 
A

You and me keep derailing. It's quite depressing. I don't want to be in a 
constant shouting game with you. I want to discuss ideas. 

/ 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

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


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

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

[Marcus Harnisch]

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


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]

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:

>>> def f(a): pass
>>> f(**dict(b=1))
TypeError: f() got an unexpected keyword argument 'b'

> Does CPython count as "other python implementation"?

Yes and No. Both are half correct. CPython is the reference
implementation. Please also consider

>>> def f(a, **kwargs): pass
>>> f(a=1, **{'a+1': 2})

>>> f(a=1, **{(0, 1): 2})
TypeError: f() keywords must be strings

So far as I know, that a keyword be a string is the only constraint,
at least in CPython. For example

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

best regards

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

[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, ironpython, who else? Without looking I'm betting they have the same implementation detail. 



I tried 
Python 2.7.10 (default, Jul 14 2015, 19:46:27)
[GCC 4.8.2] on linux
on repl.it and it says:
   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'


Does CPython count as "other python implementation"?


Wolfram
  

___
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 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 those terms, you make it far
> > broader than a simple textual transformation. Imagine if you'd said it
> > like this:
> >
> > "Okay, let's be pedantic. As well as my other proposals, I'm also
> > requiring that you be able to use 'a+b' as a variable name."
> >
> > That is most definitely not a simple proposal. And that means it
> > should be discussed as a much much broader change: disconnecting
> > keyword arguments from variable names. That should NOT just slide
> > through as part of a separate change.
>
> 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 agree that would be 
> bad. It should obviously be a separate PEP.
>

I'm not sure what you're calling irrelevant here. But sure. If you
want to propose that, propose it. Start a new thread in which you
propose that, as a language feature, kwargs are allowed to be invalid
variable names.

> I noticed you wouldn't take the bet too.

No, because the bet isn't the point. You're asking if any existing
Python implementation assumes that kwargs are valid identifiers. I
could easily create one and win the bet, and that still wouldn't be
the point. You're proposing a change to the language specification,
and that's not something to just gloss over.

When PEP 572 started proposing changes to other semantics than just
assignment expressions, there was a lot of pushback because that was
seen as an independent proposal (even though it was fairly tightly
bound to the assignment expressions themselves, in that it'd be
extremely hard to observe the difference else). What you're proposing
here is, similarly, a completely independent proposal, and not all
that tightly bound.

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] Debugging: some problems and possible solutions

[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 transformation. Imagine if you'd said it
> like this:
> 
> "Okay, let's be pedantic. As well as my other proposals, I'm also
> requiring that you be able to use 'a+b' as a variable name."
> 
> That is most definitely not a simple proposal. And that means it
> should be discussed as a much much broader change: disconnecting
> keyword arguments from variable names. That should NOT just slide
> through as part of a separate change.

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 agree that would be bad. It should 
obviously be a separate PEP. 

You could try first discussing the idea before requiring that I first state the 
legalese minutiae in exactly the right way before you even discuss the idea 
itself. 

We're pretty far away from a PEP at this stage anyway so hold your horses. This 
is python-ideas@ after all, not pep-lawyering@.

I noticed you wouldn't take the bet too. 

/ 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 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 implementation detail, NOT a language
> > > feature.
> >
> > Pedantry. Ok. Let's be pedantic: it's a simple textual transformation AND a 
> > promotion of an implementation detail to a spec requirement. Happy?
>
> 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. By restating your proposal in those terms, you make it far
broader than a simple textual transformation. Imagine if you'd said it
like this:

"Okay, let's be pedantic. As well as my other proposals, I'm also
requiring that you be able to use 'a+b' as a variable name."

That is most definitely not a simple proposal. And that means it
should be discussed as a much much broader change: disconnecting
keyword arguments from variable names. That should NOT just slide
through as part of a separate change.

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] Debugging: some problems and possible solutions

[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 be pedantic: it's a simple textual transformation AND a 
> promotion of an implementation detail to a spec requirement. Happy?

Then I'm strongly -1 on it. Happy? :)

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] Debugging: some problems and possible solutions

[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 an implementation detail to a spec requirement. Happy?

/ 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] Dictionary initialization to capture syntax and value (was Re: Debugging: some problems and possible solutions)

[Jonathan Fine]

> 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-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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 was pointed out
> > that this is merely a CPython implementation detail, NOT a language
> > feature.
>
> Here's a variant of Anders' suggestion.  First, here's a dict literal
> {'a':1, 'b': 2, 'c':3}
> and here's another way to write an equivalent dict
> dict(a=1, b=2, c=3)
>
> 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.
>
> Anders: Are you willing to accept this change, if need be?
> Chris: Please speak up, if you think this may depend on CPython.

And then you just pass the dictionary as-is? That would be plausible,
but I'm not a big fan of the syntax. Feels very clunky and forced.

Spun off as a new thread because this isn't really specific to debugging.

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] Debugging: some problems and possible solutions

[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, NOT a language
> feature.

Here's a variant of Anders' suggestion.  First, here's a dict literal
{'a':1, 'b': 2, 'c':3}
and here's another way to write an equivalent dict
dict(a=1, b=2, c=3)

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.

Anders: Are you willing to accept this change, if need be?
Chris: Please speak up, if you think this may depend on CPython.

Off topic:
https://data.grammarbook.com/blog/apostrophes/apostrophes-with-names-ending-in-s-ch-or-z/
To show singular possession of a name ending in s or z, some writers
add just an apostrophe. Others also add another s.
-- 
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]

 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 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 my_func is just a normal function:
>> 
>> def my_func(**kwargs):
>> Whatever
> 
> You're right, that case will work. I was thinking of
> 
> In [1]: foo(a+b=1)
>  File "", line 1
>foo(a+b=1)
>   ^
> SyntaxError: keyword can't be an expression

Sure. But no one suggested it either so I don't see how it's relevant. 

/ 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

[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] =', big_array[5:20])
>
> 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 my_func is just a normal function:
>
> def my_func(**kwargs):
>  Whatever

You're right, that case will work. I was thinking of

In [1]: foo(a+b=1)
  File "", line 1
foo(a+b=1)
   ^
SyntaxError: keyword can't be an expression
___
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]

>> 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 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 my_func is just a normal function:

def my_func(**kwargs):
 Whatever

It's a very simple textual transformation.

/ 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] PEPs: Theory of operation [was: Moving to another forum system ...]

[Jeroen Demeyer]

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 only question for now (in particular for PEP 580) is 
whether the old BDFL-Delegate system can still work until the new 
governance model has been decided.

___
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] PEPs: Theory of operation [was: Moving to another forum system ...]

[Wes Turner]

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-delegate org chart, or would this be the page
>> to add to and refer to?
>>
>
> re: Documenting the BDFL-Delegate process (in PEP 1?)
>
> I'm just not good with a MUA; Markdown in a linear GH issue is far easier
> to unsubscribe from; so I just added triple quotes:
>
> From "[Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580":
>
> ""'
> Jeroen Demeyer
> Hello, I would like to propose Petr Viktorin as BDFL-Delegate for PEP 580,
> titled "The C call protocol". He has co-authored several PEPs [...]
> """
>
> """
> INADA Naoki
> 2018年10月3日(水) 21:24 Jeroen Demeyer :
> > > Hello, Really? I don't know process to assign BDFL-delegate without
> BDFL. This PEP is ...
>
> Łukasz Langa
> > My understand is that accepting *any* PEP by anyone is out of the
> question until the governance situation gets resolved. That's the only
> reason why...
> """
>
> """
> On Wednesday, October 3, 2018, INADA Naoki  wrote:
>
> 2018年10月3日(水) 21:24 Jeroen Demeyer :
> Hello,
>
> >> I am well aware of the current governance issues, but several people
> have mentioned that the BDFL-Delegate process can still continue for
> now.
>
> > Really?
> > I don't know process to assign BDFL-delegate without BDFL.
> """
>
> """
> AFAIU, there is not yet a documented process for BDFL-delegate assignment.
>
> There's this in the devguide; which links to PEP1:
>
> "20.2. PEP Process¶"
> https://devguide.python.org/langchanges/#pep-process
> https://github.com/python/devguide/blob/master/langchanges.rst
>
>
> And PEP 1:
>
> "PEP 1 -- PEP Purpose and Guidelines"
>   "PEP Workflow"
> https://www.python.org/dev/peps/pep-0001/#pep-workflow
>   "PEP Editors"
> https://www.python.org/dev/peps/pep-0001/#pep-editors
>   "PEP Editor Responsibilities & Workflow"
> https://www.python.org/dev/peps/pep-0001/#pep-editor-
> responsibilities-workflow
>
> https://github.com/python/peps/blob/master/pep-0001.txt
>
> And the devguide has a list of experts:
> https://devguide.python.org/experts/
>
>
> Maybe PEP1 is the place to list current BDFL-Delegates
> (in addition to in the PEP metadata as in the OT PR:
> python/peps#797
> "PEP 580: Petr Viktorin as BDFL-Delegate"
> )?
>
>
> Not to bikeshed, but is BDFL-Delegate still the current term because
> that's what's in all the other PEPs' metadata?
> """
>
> Maybe a "delegation" GH Issue label or similar (and a commit prefix) on
> the python/peps repo would be helpful?
>


'''
On 2018-10-03 17:12, Wes Turner wrote:
> AFAIU, there is not yet a documented process for BDFL-delegate assignment.

PEP 1 says:

"""
However, whenever a new PEP is put forward, any core developer that
believes they are suitably experienced to make the final decision on
that PEP may offer to serve as the BDFL's delegate (or "PEP czar") for
that PEP. If their self-nomination is accepted by the other core
developers and the BDFL, then they will have the authority to approve
(or reject) that PEP.
"""

I know that it says "core developers and the BDFL". However, if the core
developers agree that Petr can become BDFL-Delegate, I don't see why
that wouldn't be possible.
'''

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?

(TBC, I'm +1 on the particular delegation that's not the question here)


>
>
>>
>> On Saturday, September 22, 2018, Wes Turner  wrote:
>>
>>>
>>>
>>> On Saturday, September 22, 2018, Wes Turner 
>>> wrote:
>>>

 It seems like everything's fine, but I would have no idea, BTW

>>>
>>> Would project boards be helpful for coordinating proposal status
>>> information, or extra process for something that's already working just
>>> fine?
>>>
>>> https://github.com/python/peps/projects
>>>
>>> https://github.com/pypa/interoperability-peps/projects
>>>
>>> TBH, I like Waffle.io boards, but core team may be more comfortable with
>>> GH projects with swimlanes?
>>>
>>>
 [] https://en.wikipedia.org/wiki/Quorum_call

 On Saturday, September 22, 2018, Stephen J. Turnbull <
 turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Executive summary:  Writing a PEP is an inherently uncertain process.
> Achieving "community consensus" is the goal of the process, not a
> precondition.
>
> Anders Hovmöller writes:
>
>  >  In general pep1 is frustratingly vague. Terms like “community
>  >  consensus” without defining community or what numbers would
>  >  constitute a consensus are not fun to read as someone who doesn’t
>  >  personally know anyone of the core devs. Further references to
>  >  Guido are even more frustrating now that he’s bowed out.
>
> These terms have little 

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

[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():
print(f'{k}={v}')

this is of course useful for many other things as Steven has pointed out. 

/ 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

[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 be one-- and preferably only one --obvious way to do it.
> Although that way may not be obvious at first unless you're Dutch.

However, we won't know for sure until the proposals are in.

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

[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 in terms of benefit. To quote the Zen of Python:
>
> > There should be one-- and preferably only one --obvious way to do it.
> > Although that way may not be obvious at first unless you're Dutch.
>
> However, we won't know for sure until the proposals are in.

Debugging is a massively broad area, and we commonly have and use
multiple completely different tools. Let's not start assuming that
proposals will interact or conflict until we actually have some that
do.

Your proposal for __debug__ to be able to have integer values seems
like something that should be discussed in more detail, independently
of exactly what the debugging code governed by it ends up doing. If
you do "if __debug__>2: print(f'{blah!d}')", it'd use two different
proposals, but they're completely orthogonal.

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] PEPs: Theory of operation [was: Moving to another forum system ...]

[Wes Turner]

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
> governance? (In re: to transitioning from BDFL is not dead, but)
>
> https://devguide.python.org/#contributing
>
> https://devguide.python.org/experts/
> - is there a different BDFL-delegate org chart, or would this be the page
> to add to and refer to?
>

re: Documenting the BDFL-Delegate process (in PEP 1?)

I'm just not good with a MUA; Markdown in a linear GH issue is far easier
to unsubscribe from; so I just added triple quotes:

>From "[Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580":

""'
Jeroen Demeyer
Hello, I would like to propose Petr Viktorin as BDFL-Delegate for PEP 580,
titled "The C call protocol". He has co-authored several PEPs [...]
"""

"""
INADA Naoki
2018年10月3日(水) 21:24 Jeroen Demeyer :
> > Hello, Really? I don't know process to assign BDFL-delegate without
BDFL. This PEP is ...

Łukasz Langa
> My understand is that accepting *any* PEP by anyone is out of the
question until the governance situation gets resolved. That's the only
reason why...
"""

"""
On Wednesday, October 3, 2018, INADA Naoki  wrote:

2018年10月3日(水) 21:24 Jeroen Demeyer :
Hello,

>> I am well aware of the current governance issues, but several people
have mentioned that the BDFL-Delegate process can still continue for
now.

> Really?
> I don't know process to assign BDFL-delegate without BDFL.
"""

"""
AFAIU, there is not yet a documented process for BDFL-delegate assignment.

There's this in the devguide; which links to PEP1:

"20.2. PEP Process¶"
https://devguide.python.org/langchanges/#pep-process
https://github.com/python/devguide/blob/master/langchanges.rst


And PEP 1:

"PEP 1 -- PEP Purpose and Guidelines"
  "PEP Workflow"
https://www.python.org/dev/peps/pep-0001/#pep-workflow
  "PEP Editors"
https://www.python.org/dev/peps/pep-0001/#pep-editors
  "PEP Editor Responsibilities & Workflow"
https://www.python.org/dev/peps/pep-0001/#pep-editor-responsibilities-workflow

https://github.com/python/peps/blob/master/pep-0001.txt

And the devguide has a list of experts:
https://devguide.python.org/experts/


Maybe PEP1 is the place to list current BDFL-Delegates
(in addition to in the PEP metadata as in the OT PR:
python/peps#797
"PEP 580: Petr Viktorin as BDFL-Delegate"
)?


Not to bikeshed, but is BDFL-Delegate still the current term because that's
what's in all the other PEPs' metadata?
"""

Maybe a "delegation" GH Issue label or similar (and a commit prefix) on the
python/peps repo would be helpful?


>
> On Saturday, September 22, 2018, Wes Turner  wrote:
>
>>
>>
>> On Saturday, September 22, 2018, Wes Turner  wrote:
>>
>>>
>>> It seems like everything's fine, but I would have no idea, BTW
>>>
>>
>> Would project boards be helpful for coordinating proposal status
>> information, or extra process for something that's already working just
>> fine?
>>
>> https://github.com/python/peps/projects
>>
>> https://github.com/pypa/interoperability-peps/projects
>>
>> TBH, I like Waffle.io boards, but core team may be more comfortable with
>> GH projects with swimlanes?
>>
>>
>>> [] https://en.wikipedia.org/wiki/Quorum_call
>>>
>>> On Saturday, September 22, 2018, Stephen J. Turnbull <
>>> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>>>
 Executive summary:  Writing a PEP is an inherently uncertain process.
 Achieving "community consensus" is the goal of the process, not a
 precondition.

 Anders Hovmöller writes:

  >  In general pep1 is frustratingly vague. Terms like “community
  >  consensus” without defining community or what numbers would
  >  constitute a consensus are not fun to read as someone who doesn’t
  >  personally know anyone of the core devs. Further references to
  >  Guido are even more frustrating now that he’s bowed out.

 These terms have little to do with what a new PEP's proponent needs to
 think about, though.  A PEP-able proposal by definition involves
 uncertainty.  Nobody, not even Guido, can tell you in advance whether
 a PEP will be accepted (for implementation).  The PEP process is
 rigorous enough that by the time you get close to needing consensus to
 proceed, you'll know what it means.

 "Community consensus" is not a condition for *anything* in the PEP
 process, except final acceptance.  It is the *goal* of the process.
 PEPs are approved (for publication) by default; the only requirement
 is editorial completeness.  PEPs are needed for two reasons: (1) to
 get the input of the community, both highly competent engineers for
 implementation and a variety of users for requirements, to refine a
 complex proposal or one with far-reaching implications for the
 language, and/or (2) to build a 

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

[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, independently of
any other proposals? Do they interact with each other?

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] Debugging: some problems and possible solutions

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

POSSIBLE SOLUTION
At present, __debug__ is a keyword identifier, which can take only the
values True and False. It gets its value on Python startup, and then
its value can't be changed.

The possible solution is to allow Python startup to give __debug__ an
additional value, namely 2. Once this is done, code blocks such as
if __debug__ >= 2:
# my debug-only code goes here
will effectively be ignored, except when requested.

Python already does this for blocks such as
if __debug__:
# ignored if optimised code is being generated

See also: https://docs.python.org/3/library/constants.html#__debug__
__debug__
This constant is true if Python was not started with an -O option.
See also the assert statement.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jonathan Fine]

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.

-- 
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] f-string "debug" conversion

[Ivan Levkivskyi]

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 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 want is an executable object (a function?) which has the
> > AST and text of the expression attached. If putting this into f-strings
> > is a first step towards getting this thunk-like thing, then I don't
> > need to read any further, I'm +1 :-)
>
> I feel your pain, but we're a long way from that.
>

Maybe we are actually not so far? PEP 563 added functionality for
transforming expressions to strings, maybe it can be reused for this
purpose?
I would love to have this since in my experience I mostly print some
(relatively complex) expressions.

--
Ivan
___
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 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 by an
equal sign, followed by the repr of the value of the expression. 


...

The result is a string, so if you really wanted to, you could use a
string formatting spec. So:

print(f'*{value!d:^20}*'

would produce:

*      value=10      *

Although I don’t think that would be very useful in general.


Me neither ;-)  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 repe is almost never what I want to see.


 >>> f"math.pi={math.pi:.2f}"
'math.pi=3.14'

I have plenty of code already embedding stuff of the form

     EXPR {EXPR:FMT}

and don't really care whether there's a space or an "=" between the 
chunks.  "!d" could act like a macro-expansion operator automating a 
mechanical transformation inside the f-string.  Then I could read "!d" 
as "duplicate" instead of as "debug" ;-)


That's a very interesting idea. It breaks the expectation (which might 
be mine alone!) that the format spec is used on the result of the 
conversion specifier (!s, !r). But maybe that's okay. It does seem 
generally more useful than the format spec being used on the repr of the 
evaluated expression.


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] f-string "debug" conversion

[Eric V. Smith]

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() exists, I can't really see myself using this.
 >
 > I also don't see the use case of it being within an f-string, because 
I've
 > never had to interpolate a debug string within some other string or 
format
 > it in a fancy way. You said it yourself, taking advantage of other 
f-string

 > features isn't very useful in this case.
 >
 > If other people can find a use for it, I'd suggest making it ita own
 > function -- debug(value) or something similar.

There was some discussion of this back in April:

https://mail.python.org/pipermail/python-ideas/2018-April/050113.html


Worth pointing out from that discussion is the "q" library: 
https://pypi.org/project/q/. I got excited about it back then, but never 
installed it.



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 map e.g. a CALL operation to the exact start and end positions of 
that call expression in the source. This is free at runtime, and would 
allow more detailed tracebacks (see [1] for an example), and more 
detailed coverage information. It would definitely take some work to 
thread the necessary information through the compiler infrastructure, 
but I think this would be a worthwhile feature even without the debug() 
use case.


Step 2: Add a 'debug' helper function that exploits the detailed 
information to reconstruct its call, by peeking into the calling frame 
and finding the source for the call. Of course this would be a strange 
and ugly thing to do for a regular function, but for a debugging helper 
it's reasonable. So e.g. if you had the code:


   total = debug(x) + debug(y / 10)

The output might be:

   debug:myfile.py:10: 'x' is 3
   debug:myfile.py:10: 'y / 10' is 7


I'm not positive, but isn't this what q does?

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] f-string "debug" conversion

[Eric V. Smith]

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


You gave as one of several examples that given
 value = 10
the expression
 f'{value!d}'
evaluates to
 'value=10'
which can then be printed or logged.

I thank you and Larry Hastings for coming up with and exploring this idea.

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.


I don't think a simple f-string feature needs a PEP. The implementation 
is pretty simple, since the f-string parser already has access to the 
string.



The present discussion thread is spreading into other areas, such as
what constitutes the Python language specification. I'd like to
contribute to a broader discussion, of how we can improve the
debugging experience. But I feel uncomfortable doing so in a
discussion thread that started with your admirably clear focus.

Briefly, Eric, would you like the general discussion of improving
debugging to take place in this thread, or in another.


I think it would be more productive as a separate thread.


Finally, if I may I thank you and Larry for your work on this
important topic, and for starting this useful discussion.


Thanks. It's what we do!

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] f-string "debug" conversion

[Eric V. Smith]

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!),


I SO WANT THIS AS A GENERAL FEATURE, not just for f-strings, it hurts.

Actually what I want is an executable object (a function?) which has the
AST and text of the expression attached. If putting this into f-strings
is a first step towards getting this thunk-like thing, then I don't
need to read any further, I'm +1 :-)


I feel your pain, but we're a long way from that.


produces:

value=10
next: value+1=11
s='a string!'


I can see lots of arguments about whether the equals sign should have
spaces around it.

Maybe !d for no spaces and !D for spaces?

print(f'next: {value+1!d}')
print(f'next: {value+1!D}')

would print

next: value+1=11
next: value+1 = 11


I'm not sure it's worth the hassle. I considered a whole format spec 
language for this, but it sort of got out of hand.



I’m not proposing this for str.format(). It would only really make sense
for named arguments, and I don’t think
print('{value!d}'.format(value=value) is much of a win.


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!")=39'

which I can see being very useful in debugging expressions.


Yes, that's part of the proposal, but I wasn't very clear. That's what 
the "value+1" example was supposed to convey. My comment about named 
parameters applied only to str.format(), and why it won't be supported 
there.


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] f-string "debug" conversion

[Steven D'Aprano]

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 was what it was. That was not intended to be about magic, that 
> was the normal case where you didn't want the magic.

Oh I'm sorry, I admit I read your earlier post wrongly. I missed that 
you were focused on the "=args" syntactic sugar and imagined you were 
proposing a magic debug() function as an alternative to this proposed 
f-string feature.

The perils of skim reading. Mea culpa.



-- 
Steve
___
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

[Chris Angelico]

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.

At this point, I don't think this requires a PEP. If it does in the
future, or if competing proposals emerge, then a PEP could be written,
but it'd be overkill at the moment.

Chris Angelico
PEP Editor
___
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

[Anders Hovmöller]

> 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 we can improve the
> debugging experience. But I feel uncomfortable doing so in a
> discussion thread that started with your admirably clear focus.

Please reconsider! We need more view points and good ideas.

/ 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

[Jonathan Fine]

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

You gave as one of several examples that given
value = 10
the expression
f'{value!d}'
evaluates to
'value=10'
which can then be printed or logged.

I thank you and Larry Hastings for coming up with and exploring this idea.

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.

The present discussion thread is spreading into other areas, such as
what constitutes the Python language specification. I'd like to
contribute to a broader discussion, of how we can improve the
debugging experience. But I feel uncomfortable doing so in a
discussion thread that started with your admirably clear focus.

Briefly, Eric, would you like the general discussion of improving
debugging to take place in this thread, or in another.

Finally, if I may I thank you and Larry for your work on this
important topic, and for starting this useful discussion.

-- 
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] f-string "debug" conversion

[Nicolas Rolin]

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"interesting_variable_name={interesting_variable_name},
big_list[:10]={big_list[:10]}".



2018-10-03 11:17 GMT+02:00 Chris Angelico :

> 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
> language spec, there is only CPython. This has been the experience and
> approach of PyPy as far as I've understood it after having followed their
> blog over the years.
> > >>
> > >
> > > Definitely not true. There have been times when other implementors
> > > have come to python-dev and said, hey, is this part of the spec or is
> > > it an implementation detail? And the answer determines whether they
> > > care about that or not. For just a few examples:
> > >
> > > 1) Reference counting vs nondeterministic garbage collection
> > > 2) O(1) indexing/slicing of Unicode strings
> > > 3) "\N{...}" string escapes (okay, that's standardized, but optional)
> > > 4) Reuse of id() values
> > > 5) The "slots" mechanism for dunder method lookup
> > >
> > > The language spec determines, in some cases, that a CPython
> > > implementation detail has been promoted to standard. More often, it
> > > determines that other Pythons are permitted to behave differently.
> >
> > Sometimes they will come away from this list thinking they don't care
> but then their users will report bugs over and over again and they'll just
> have to do it anyway. You probably won't hear about most of those. Trees
> that fall in the forest when no one is there do in fact make a sound.
> >
>
> And sometimes, people all over the world learn to write "with
> open(...) as f:" instead of just letting f expire. There IS a language
> spec, and pretending there isn't one doesn't change that.
>
> 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/
>



-- 

--
*Nicolas Rolin* | Data Scientist
+ 33 631992617 - nicolas.ro...@tiime.fr 


*15 rue Auber, **75009 Paris*
*www.tiime.fr *
___
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

[Chris Angelico]

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 
> >> language spec, there is only CPython. This has been the experience and 
> >> approach of PyPy as far as I've understood it after having followed their 
> >> blog over the years.
> >>
> >
> > Definitely not true. There have been times when other implementors
> > have come to python-dev and said, hey, is this part of the spec or is
> > it an implementation detail? And the answer determines whether they
> > care about that or not. For just a few examples:
> >
> > 1) Reference counting vs nondeterministic garbage collection
> > 2) O(1) indexing/slicing of Unicode strings
> > 3) "\N{...}" string escapes (okay, that's standardized, but optional)
> > 4) Reuse of id() values
> > 5) The "slots" mechanism for dunder method lookup
> >
> > The language spec determines, in some cases, that a CPython
> > implementation detail has been promoted to standard. More often, it
> > determines that other Pythons are permitted to behave differently.
>
> Sometimes they will come away from this list thinking they don't care but 
> then their users will report bugs over and over again and they'll just have 
> to do it anyway. You probably won't hear about most of those. Trees that fall 
> in the forest when no one is there do in fact make a sound.
>

And sometimes, people all over the world learn to write "with
open(...) as f:" instead of just letting f expire. There IS a language
spec, and pretending there isn't one doesn't change that.

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

[Anders Hovmöller]

>> 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 and approach of 
>> PyPy as far as I've understood it after having followed their blog over the 
>> years.
>> 
> 
> Definitely not true. There have been times when other implementors
> have come to python-dev and said, hey, is this part of the spec or is
> it an implementation detail? And the answer determines whether they
> care about that or not. For just a few examples:
> 
> 1) Reference counting vs nondeterministic garbage collection
> 2) O(1) indexing/slicing of Unicode strings
> 3) "\N{...}" string escapes (okay, that's standardized, but optional)
> 4) Reuse of id() values
> 5) The "slots" mechanism for dunder method lookup
> 
> The language spec determines, in some cases, that a CPython
> implementation detail has been promoted to standard. More often, it
> determines that other Pythons are permitted to behave differently.

Sometimes they will come away from this list thinking they don't care but then 
their users will report bugs over and over again and they'll just have to do it 
anyway. You probably won't hear about most of those. Trees that fall in the 
forest when no one is there do in fact make a sound.

/ 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

[Chris Angelico]

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, there is only CPython. This has been the experience and approach of 
> PyPy as far as I've understood it after having followed their blog over the 
> years.
>

Definitely not true. There have been times when other implementors
have come to python-dev and said, hey, is this part of the spec or is
it an implementation detail? And the answer determines whether they
care about that or not. For just a few examples:

1) Reference counting vs nondeterministic garbage collection
2) O(1) indexing/slicing of Unicode strings
3) "\N{...}" string escapes (okay, that's standardized, but optional)
4) Reuse of id() values
5) The "slots" mechanism for dunder method lookup

The language spec determines, in some cases, that a CPython
implementation detail has been promoted to standard. More often, it
determines that other Pythons are permitted to behave differently.

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

[Anders Hovmöller]

>> 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 where you didn't want the magic. I think you might be taking a 
habit of interpreting my mails in the least flattering way due to our previous 
disagreements. I hope we can put this behind us going forward.

> Things which contain compiler magic should look special, not like 
> ordinary function calls.

Good. I agree :P


>>> AIUI, keyword arguments are all supposed to be legal names/atoms, so
>>> you aren't supposed to do something like this:
>>> 
>>> debug(**{"value+1":value+1})
>> 
>> Really? That seems pretty weird to me. I’ve used that type of thing in 
>> production code from time to time.
> 
> The fact that this works is, I think, an accident of implementation:
> 
> py> def spam(**kw):
> ... print(kw)
> ...
> py> spam(**{"value+1": 42})
> {'value+1': 42}
> 
> rather than a guaranteed language feature. I can't find any relevent 
> documentation on it, but I'd be very wary about relying on it.
> 
> (To be honest, I expected it to fail until I tried it.)


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 and approach of PyPy 
as far as I've understood it after having followed their blog over the years.

/ 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

[Chris Angelico]

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!")=39'
>
> which I can see being very useful in debugging expressions.

Absolutely! I can't imagine doing *hugely* complex expressions, but consider:

print(f"{request.args!d}")

Technically that's an "arbitrary expression" and is most definitely
not a named argument, but it's the sort of thing where you really do
want the tag to say "request.args" and not just "args" or anything
like that. Ideally, I'd like to be able to write this as:

dump(request.args)

and have it pick up both the string "request.args" and the value of
request.args, but the f-string variant is absolutely okay with me as a
partial solution.

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

[Chris Angelico]

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 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".
>
> Things which contain compiler magic should look special, not like
> ordinary function calls.
>
>
> > > AIUI, keyword arguments are all supposed to be legal names/atoms, so
> > > you aren't supposed to do something like this:
> > >
> > > debug(**{"value+1":value+1})
> >
> > Really? That seems pretty weird to me. I’ve used that type of thing in
> > production code from time to time.
>
> The fact that this works is, I think, an accident of implementation:
>
> py> def spam(**kw):
> ... print(kw)
> ...
> py> spam(**{"value+1": 42})
> {'value+1': 42}
>
> rather than a guaranteed language feature. I can't find any relevent
> documentation on it, but I'd be very wary about relying on it.
>
> (To be honest, I expected it to fail until I tried it.)

I can't find any documentation either, but ISTR it's been stated as a
CPython implementation detail, not a language feature. Other Pythons
are entirely free to reject this.

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

[Steven D'Aprano]

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 
function "debug" and takes a simple keyword argument next with value 
"value+1".

Things which contain compiler magic should look special, not like 
ordinary function calls.


> > AIUI, keyword arguments are all supposed to be legal names/atoms, so
> > you aren't supposed to do something like this:
> > 
> > debug(**{"value+1":value+1})
> 
> Really? That seems pretty weird to me. I’ve used that type of thing in 
> production code from time to time.

The fact that this works is, I think, an accident of implementation:

py> def spam(**kw):
... print(kw)
...
py> spam(**{"value+1": 42})
{'value+1': 42}

rather than a guaranteed language feature. I can't find any relevent 
documentation on it, but I'd be very wary about relying on it.

(To be honest, I expected it to fail until I tried it.)

You certainly can't do this:

py> spam(value+1=42)
  File "", line 1
SyntaxError: keyword can't be an expression



-- 
Steve
___
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

[Anders Hovmöller]

>> 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 want is an executable object (a function?) which has the 
> AST and text of the expression attached. If putting this into f-strings 
> is a first step towards getting this thunk-like thing, then I don't 
> need to read any further, I'm +1 :-)

Well... this is a trivial expansion of the keyword argument short form proposal 
you were very strongly opposed ^_-

So, I suggested `foo(=a)` as short form for `foo(a=a)`, but if we interpret it 
instead as `foo(=a)` -> `foo(**{'a': a}`, which is really the same thing for 
most purposes, then we could trivially get `foo(=1+3*bar)` -> 
'foo(**{'1+3*bar': 1+3*bar})'

I'm fine with this proposal. And thanks Chris for the idea!

/ 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

[Steven D'Aprano]

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, not just for f-strings, it hurts.

Actually what I want is an executable object (a function?) which has the 
AST and text of the expression attached. If putting this into f-strings 
is a first step towards getting this thunk-like thing, then I don't 
need to read any further, I'm +1 :-)

But considering the proposal as you give it:


> followed by an 
> equal sign, followed by the repr of the value of the expression. So:
> 
> value = 10
> s = 'a string!'
> print(f'{value!d}')
> print(f'next: {value+1!d}')
> print(f'{s!d}')
> 
> produces:
> 
> value=10
> next: value+1=11
> s='a string!'

I can see lots of arguments about whether the equals sign should have 
spaces around it. 

Maybe !d for no spaces and !D for spaces?

print(f'next: {value+1!d}')
print(f'next: {value+1!D}')

would print

next: value+1=11
next: value+1 = 11



> I’m not proposing this for str.format(). It would only really make sense 
> for named arguments, and I don’t think 
> print('{value!d}'.format(value=value) is much of a win.

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!")=39'

which I can see being very useful in debugging expressions.


This is perhaps the first time I've been excited and enthusiastic about 
f-strings. A definite +1 on this.


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