[Python-ideas] Re: Print and eval
Hi Evan,
f-strings support a version of this. If you put an equals sign at the
end of the expression in your f-string (possibly with white space) then
the f-string will include both the expression itself and its value in
the result:
>>> a = 12; b = 13
>>> f'{a == b}'
'False'
>>> f'{a == b = }'
'a == b = False'
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/SAGY3JUDJBGZDL3HU6SBJRCBX5XHW37G/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Print and eval
Are you familiar with the f-string self-documentation operator in python
3.8?
https://docs.python.org/3/whatsnew/3.8.html#f-strings-support-for-self-documenting-expressions-and-debugging
With it you can say:
print(f"{a==b=}")
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
On Mon, Nov 1, 2021 at 10:31 PM Evan Greenup via Python-ideas <
python-ideas@python.org> wrote:
> It would be nice to add the following syntax sugar in Python "Print and
> Eval"
>
> like `ptev a == b` It is same as `statement = "a == b";
> print(f"{statement} ? {eval(statement)}")`.
>
> It would super nice for debugging and other research project.
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/NQ6NZIALIVNNVMYZSSFF7Y2Q4W736O7L/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/A4P2HXIT2C5EY5DPW65XBTCYHYZB4XBY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Print and eval
On Tue, Nov 2, 2021 at 1:31 PM Evan Greenup via Python-ideas
wrote:
>
> It would be nice to add the following syntax sugar in Python "Print and Eval"
>
> like `ptev a == b` It is same as `statement = "a == b"; print(f"{statement} ?
> {eval(statement)}")`.
>
> It would super nice for debugging and other research project.
>
At the REPL, that basically already happens, but if this is something
you're doing a lot of in your code, you might be able to take
advantage of this feature of f-strings:
>>> a = 5
>>> b = 5.0
>>> f"{a == b = }"
'a == b = True'
Very handy for quick debugging.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/CLZW3YH2EHP2VMRWIDH7NA7LE4PYXPYL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Print and eval
It would be nice to add the following syntax sugar in Python "Print and Eval"
like `ptev a == b` It is same as `statement = "a == b"; print(f"{statement} ?
{eval(statement)}")`.
It would super nice for debugging and other research project.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/NQ6NZIALIVNNVMYZSSFF7Y2Q4W736O7L/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults
On Mon, Nov 1, 2021 at 7:39 PM Evpok Padding wrote: > > I definitely agree with that sentiment, with beginners I don't even talk > about function defaults at first, and when I do, it's when we have already > have a talk about mutables so I can just say that you almost never want a > mutable default but rather use None as a sentinel. It's not that hard and it > serves as a reminder of how mutables work, so it's actually good for teaching! > Or you can just say "but rather use => when defining the default", and then you don't have to explain more things like whether to use "== None" or "is None" just to show how to have a default that builds a new thing. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PYJDIOOZSOU2N7UFTAF7BB75DZWX2UV2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults
On Mon, Nov 01, 2021 at 09:39:01AM +0100, Evpok Padding wrote:
> I don't look forward to having to add yet another side note about syntactic
> sugar that does not really add much value (it saves a few characters but
> it's less clear
This proposal is not about saving a few characters. We could keep the
PEP and change the syntax to use a long keyword:
def func(arg=late_binding_through_delayed_evaluation expression)
(where "expression" is an actual expression) and it would still have the
same benefits. Just more awkward to type :-)
> and relying on code to document the parameters is a bit meh
> imo).
Do you think it is a problem that help() can introspect function
signatures and report what the actual defaults are, rather than whatever
lies are put in the docstring? I think that is a fantastic feature for
Python, but it only applies to early defaults.
def func(arg=''):
"""Return a thing.
Arguments: arg is a string, defaults to space.
"""
When possible, the single source of truth for a function's defaults
should be the actual parameter defaults, regardless of when the default
is evaluated.
> Because I won't burden beginners who are already having to ingest a
> lot of thing with a new model of evaluation.
We're not proposing this feature for the benefit of newbies and
beginners. Python is remarkably beginner friendly, but it's not Scratch.
The first edition of Learning Python (Mark Lutz and David Ascher) didn't
introduce function defaults until page 122, right at the end of Chapter
Four. And of course they had to mention the mutable object gotcha. We do
people a disservice if we don't introduce at least the concept of when
the default is evaluated. If we don't, they will invariably trip into
the "mutable default" gotcha on their own and confuse themselves.
I don't think the distinction between early and late binding is a hard
concept to teach. What does this do?
def func(arg=print("Hello")):
return arg
func()
func()
That's all you need to show to demonstrate early binding. Now this:
def func(arg=late print("Hello")):
return arg
func()
func()
Having *both* options available, and teaching it as a choice, will (I
think) make it easier to teach, not harder.
"Write `arg=default` if you want the default to be evaluated just once,
and `arg=late default` if you want the default to be evaluated each time
it is needed. If you are not sure which one you need, use the first."
That's the sort of advice I would have loved when I was a newbie. Short,
simple, straight to the point, and not reliant on knowing what "is None"
means.
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/WU7S56ZHGYU4V5OZNF6KIDFDR3OZKMTG/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults
I definitely agree with that sentiment, with beginners I don't even talk about function defaults at first, and when I do, it's when we have already have a talk about mutables so I can just say that you almost never want a mutable default but rather use None as a sentinel. It's not that hard and it serves as a reminder of how mutables work, so it's actually good for teaching! I don't look forward to having to add yet another side note about syntactic sugar that does not really add much value (it saves a few characters but it's less clear and relying on code to document the parameters is a bit meh imo). Because I won't burden beginners who are already having to ingest a lot of thing with a new model of evaluation. I guess an alternative could be to only teach late binding but since all the code written so far is early bound, it's not practical. Cheers, E On Mon, 1 Nov 2021, 01:05 Brendan Barnwell, wrote: > On 2021-10-31 15:08, Chris Angelico wrote: > > On Mon, Nov 1, 2021 at 8:56 AM David Mertz, Ph.D. > > wrote: > >> I am not on the SC, so indeed I won't make the decision. But I > >> *will* continue to teach Python. New syntax adds a burden to > >> learners, and it should not be introduced without sufficient > >> benefit to merit that burden. This proposal does not come close to > >> that threshold. > >> > > > > How do you currently teach about mutable argument defaults? With > > this proposal, it will become trivially easy to have an argument > > default that's evaluated fresh every time. Does that not count as > > beneficial? > > This is a good question. When I've taught Python, I teach about > mutable argument defaults by building on what's been taught about > mutable objects in general. As we know, there are many things about > mutable objects that can confuse newbies (or even people with some > experience), and many of them have nothing to do with default arguments. > For instance, people are sometimes surprised if they do > > x = [1, 2, 3] > some_function(x) > > . . . and then find that x has changed in the calling environment > because `some_function` mutated it. Or sometimes they're surprised > "from the inside" because they're the one writing `some_function` and > they mutate the argument and didn't realize that could disrupt other > code that calls their function. And so on. > > Once people understand the general need to be careful about > mutable > objects and where they're mutated, using them as object defaults is not > really a huge additional obstacle. Basically you just have to make > clear that defaults are evaluated only once, when they write the > function, and not again and again each time it is called. If people > understand that, they will basically understand mutable argument > defaults, because that is essentially the same situation in the example > above, and various other cases. It just means "be careful when you > mutate a mutable object someone else might be using that object too". > > Of course, they will forget this and make mistakes. So having > late-bound defaults would be a bit of a help. But my point is that many > of the problems learners have with mutable default arguments are really > problems with mutable objects in general, and having late-bound defaults > won't help with those more general confusions. > > So the situation is the same as before: yes, there will be a bit > of a > benefit, but the benefit is limited. Also, from a teaching perspective, > there is an important cost as well, which is that you have to teach > students about the new syntax and how it differs from early-bound > defaults, and students have to develop the skill of reading function > signatures that are now (potentially) more complex than they were before. > > Based on my own (admittedly limited) experience I'm not sure if > late-bound defaults would be a net win in terms of teaching ease. Right > now the situation is actually not too crazy to explain because the > handling of mutable defaults (i.e., the "if arg is None" stuff) goes > into the function body and can be described as part of other general > "prep work" that functions may need to do at the beginning (like, say, > converting inputs to lowercase or doing some sanity checks on > arguments). But the new proposal is something that would actually have > to be learned as a separate thing because of its in-between nature > (i.e., now the argument list becomes a mix of things, some of which > execute in the defining context and some in the calling context). > > -- > Brendan Barnwell > "Do not follow where the path may lead. Go, instead, where there is no > path, and leave a trail." > --author unknown > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.pyth
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults
On Mon, Nov 1, 2021 at 5:57 PM Guido van Rossum wrote: > > Agreed, class namespaces are weird. :-) > Ah yes, I forgot about class namespaces. I was thinking about deliberately wonky namespaces where the ns dict has a __missing__ method or something, but inside a class, "b = b" actually has a very useful meaning :) It still doesn't change the behaviour of the object b though. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/T3GSNI4SBHAWYTDLJKGNOUJXL2ISA62R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults
Agreed, class namespaces are weird. :-) On Sun, Oct 31, 2021 at 23:38 Chris Angelico wrote: > On Mon, Nov 1, 2021 at 5:15 PM Greg Ewing > wrote: > > > > On 1/11/21 4:59 am, David Mertz, Ph.D. wrote: > > > b = b > > > > I don't want to live in a universe where this could be anything > > other than a no-op in Python. > > > > Be careful what you say: there are some technicalities. If you mean > that it won't change the behaviour of the object referred to by b, > then I absolutely agree, but there are ways that this can be more than > a no-op. Notably, it has very good meaning as a keyword argument (it > means "pass b along, named b"), and as a function parameter (meaning > "accept b, defaulting to b from the outer scope"); and even as a > stand-alone statement, it isn't technically meaningless (it'll force b > to be a local). > > But yes, I agree that I don't want this to force the evaluation of > something, which continues to be called b. Even though that's > technically possible already if you have a weird namespace, I wouldn't > call that a good way to write code. > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/HQI3ULA6ZAYEHU7JMKZYLLTAG2IFWIVI/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YSQZOQ4TG7X2KBEOR37GMBQOTPECMTPI/ Code of Conduct: http://python.org/psf/codeofconduct/
