[Python-Dev] Re: Roundup to GitHub Issues migration

2021-06-24 Thread Barry Warsaw
That sounds great, thanks Mariatta.

-Barry

> On Jun 23, 2021, at 12:36, Mariatta  wrote:
> 
> My understanding is that Ezio is/will be working on updating PEP 588.
> Last I heard from Ezio is that he would be co-author of PEP 588 and he would 
> be updating it/rewrite it to better match the current migration plan.
> 
> I will check with Ezio and the gh-migration group on the status.
> 
> Thanks.
> 
> On Wed, Jun 23, 2021 at 10:33 AM Barry Warsaw  wrote:
> 
> 
> Mariatta is the author of PEP 588 and I’m the delegate.  Given how old that 
> PEP is and the fact that Ezio is managing the project elsewhere, I think 
> rejection is appropriate.  However if we do that I think the PEP should at 
> least be updated with references to Ezio’s project, with some verbiage added 
> as to why these changes are being made.
> 
> What do you think, Mariatta?
> 
> -Barry
> 



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5VU3AM55K6DM4FKROGOFUX6OZLYLZ363/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Delayed evaluation of f-strings?

2021-06-24 Thread Eric Nieuwland
In a recent discussion with a colleague we wondered if it would be possible to 
postpone the evaluation of an f-string so we could use it like a regular string 
and .format() or ‘%’.

I found 
https://stackoverflow.com/questions/42497625/how-to-postpone-defer-the-evaluation-of-f-strings
 and tweaked it a bit to:

import inspect

class DelayedFString(str):
def __str__(self):
vars = inspect.currentframe().f_back.f_globals.copy()
vars.update(inspect.currentframe().f_back.f_locals)
return self.format(**vars)

delayed_fstring = DelayedFString("The current name is {name}")

# use it inside a function to demonstrate it gets the scoping right
def new_scope():
names = ["foo", "bar"]
for name in names:
print(delayed_fstring)

new_scope()

While this does what it should it is very slow.
So I wondered whether it would be an idea to introduce d-strings (delayed 
f-strings) and make f-strings syntactic sugar for

f"The current name is {name}" = str(d"The current name is {name}")

And perhaps access to the variables and conversions specified in the d-string.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GT5DNA7RKRLFWE3V42OTWB7X5ER7KNSL/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Delayed evaluation of f-strings?

2021-06-24 Thread Thomas Grainger
for your usecase I'd write:


def delayed_fstring(*, name: str) -> str:
return "The current name is {name}"

def new_scope() -> None:
for name in ["foo", "bar"]:
print(delayed_fstring(name=name))


for logging I use:

class Msg:
def __init__(self, fn: Callable[[], str]):
self._fn = fn

def __str__(self) -> str:
return self._fn()
...
logger.info(Msg(lambda: f"The current name is {name}"))
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZXRUDEMIY4AV3SIVIEAWHFKFMPGOLI4J/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Delayed evaluation of f-strings?

2021-06-24 Thread Martin (gzlist) via Python-Dev
On Thu, 24 Jun 2021 at 17:25, Eric Nieuwland  wrote:
>
> class DelayedFString(str):
> def __str__(self):
> vars = inspect.currentframe().f_back.f_globals.copy()
> vars.update(inspect.currentframe().f_back.f_locals)
> return self.format(**vars)

This isn't quite right as the semantics between f-strings and
str.format() are not actually the same (though this isn't well
documented):

>>> f'{1 + 2}'
'3'
>>> str(DelayedFString('{1 + 2}'))
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 5, in __str__
KeyError: '1 + 2'

>>> d = dict(a=1)
>>> f'{d["a"]}'
'1'
>>> str(DelayedFString('{d["a"]}'))
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 5, in __str__
KeyError: '"a"'

Basically, f-strings rely on eval-like semantics.

Martin
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HGITYZPPRXJM4Y7YVJKUSVXUB75W5Z2L/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Delayed evaluation of f-strings?

2021-06-24 Thread Martin (gzlist) via Python-Dev
On Thu, 24 Jun 2021 at 17:37, Martin (gzlist)  wrote:
>
> >>> d = dict(a=1)
> >>> f'{d["a"]}'
> '1'
> >>> str(DelayedFString('{d["a"]}'))
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 5, in __str__
> KeyError: '"a"'

And the other side of the attribute lookup:

>>> d = dict(a=1)
>>> str(DelayedFString('{d[a]}'))
'1'
>>> f'{d[a]}'
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'a' is not defined

Yes, having three different ways of doing string interpolation (not
counting other things you can import, like string.Template) is a bit
confusing.

Martin
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/A7FQUWQND56VGHCTTCFW6XDNCWP5MVNM/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Delayed evaluation of f-strings?

2021-06-24 Thread Luciano Ramalho
I don't think that would be a good idea since we already have
.format() which covers that use case and is more flexible than
f-strings (it supports positional arguments, as well as *args and
**kwargs).

I think keeping f-strings simple is a better idea.

Best,

Luciano

On Thu, Jun 24, 2021 at 1:30 PM Eric Nieuwland  wrote:
>
> In a recent discussion with a colleague we wondered if it would be possible 
> to postpone the evaluation of an f-string so we could use it like a regular 
> string and .format() or ‘%’.
>
> I found 
> https://stackoverflow.com/questions/42497625/how-to-postpone-defer-the-evaluation-of-f-strings
>  and tweaked it a bit to:
>
> import inspect
>
> class DelayedFString(str):
> def __str__(self):
> vars = inspect.currentframe().f_back.f_globals.copy()
> vars.update(inspect.currentframe().f_back.f_locals)
> return self.format(**vars)
>
> delayed_fstring = DelayedFString("The current name is {name}")
>
> # use it inside a function to demonstrate it gets the scoping right
> def new_scope():
> names = ["foo", "bar"]
> for name in names:
> print(delayed_fstring)
>
> new_scope()
>
>
> While this does what it should it is very slow.
> So I wondered whether it would be an idea to introduce d-strings (delayed 
> f-strings) and make f-strings syntactic sugar for
>
> f"The current name is {name}" = str(d"The current name is {name}")
>
>
> And perhaps access to the variables and conversions specified in the d-string.
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/GT5DNA7RKRLFWE3V42OTWB7X5ER7KNSL/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LVPDNGURA677ODMLBVUURPXKYGBKJ6A4/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Delayed evaluation of f-strings?

2021-06-24 Thread Eric Nieuwland
I didn’t make myself clear, sorry.

The code example was just to give an initial what I was suggesting.
The errors you show demonstrate the example is incomplete.
I’d like them to work.

> On 24 Jun 2021, at 18:37, Martin (gzlist)  wrote:
> 
> On Thu, 24 Jun 2021 at 17:25, Eric Nieuwland  wrote:
>> 
>> class DelayedFString(str):
>>def __str__(self):
>>vars = inspect.currentframe().f_back.f_globals.copy()
>>vars.update(inspect.currentframe().f_back.f_locals)
>>return self.format(**vars)
> 
> This isn't quite right as the semantics between f-strings and
> str.format() are not actually the same (though this isn't well
> documented):
> 
 f'{1 + 2}'
>'3'
 str(DelayedFString('{1 + 2}'))
>Traceback (most recent call last):
>  File "", line 1, in 
>  File "", line 5, in __str__
>KeyError: '1 + 2'
> 
 d = dict(a=1)
 f'{d["a"]}'
>'1'
 str(DelayedFString('{d["a"]}'))
>Traceback (most recent call last):
>  File "", line 1, in 
>  File "", line 5, in __str__
>KeyError: '"a"'
> 
> Basically, f-strings rely on eval-like semantics.
> 
> Martin

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/L5U7ES6PS5LW532PAP62CD4PU55WEBAI/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Delayed evaluation of f-strings?

2021-06-24 Thread Eric Nieuwland
Except I like the mini-language of f-strings much better than format()’s.
And there is a performance difference between f-strings and format().


> On 24 Jun 2021, at 19:03, Luciano Ramalho  wrote:
> 
> I don't think that would be a good idea since we already have
> .format() which covers that use case and is more flexible than
> f-strings (it supports positional arguments, as well as *args and
> **kwargs).
> 
> I think keeping f-strings simple is a better idea.
> 
> Best,
> 
> Luciano
> 
> On Thu, Jun 24, 2021 at 1:30 PM Eric Nieuwland  
> wrote:
>> 
>> In a recent discussion with a colleague we wondered if it would be possible 
>> to postpone the evaluation of an f-string so we could use it like a regular 
>> string and .format() or ‘%’.
>> 
>> I found 
>> https://stackoverflow.com/questions/42497625/how-to-postpone-defer-the-evaluation-of-f-strings
>>  and tweaked it a bit to:
>> 
>> import inspect
>> 
>> class DelayedFString(str):
>>def __str__(self):
>>vars = inspect.currentframe().f_back.f_globals.copy()
>>vars.update(inspect.currentframe().f_back.f_locals)
>>return self.format(**vars)
>> 
>> delayed_fstring = DelayedFString("The current name is {name}")
>> 
>> # use it inside a function to demonstrate it gets the scoping right
>> def new_scope():
>>names = ["foo", "bar"]
>>for name in names:
>>print(delayed_fstring)
>> 
>> new_scope()
>> 
>> 
>> While this does what it should it is very slow.
>> So I wondered whether it would be an idea to introduce d-strings (delayed 
>> f-strings) and make f-strings syntactic sugar for
>> 
>> f"The current name is {name}" = str(d"The current name is {name}")
>> 
>> 
>> And perhaps access to the variables and conversions specified in the 
>> d-string.
>> 
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at 
>> https://mail.python.org/archives/list/python-dev@python.org/message/GT5DNA7RKRLFWE3V42OTWB7X5ER7KNSL/
>> Code of Conduct: http://python.org/psf/codeofconduct/
> 
> 
> 
> -- 
> Luciano Ramalho
> |  Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> |  Technical Principal at ThoughtWorks
> |  Twitter: @ramalhoorg

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YJQDXGTFX7G2P6OLYT3QF3IFN7Z65FSG/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Delayed evaluation of f-strings?

2021-06-24 Thread micro codery
As pointed out already, f-strings and format are subtly different (not
counting that one can eval and the other cannot). Besides quoting, the
f-sting mini language has diverged from format's
>>> spam="Spam"
>>> f"{spam=}"
"spam='Spam'"
>>> "{spam=}".format(spam=spam)
Traceback (most recent call last):
  File "", line 1, in 
KeyError: 'spam='

I created a package some time ago to do exactly this
https://pypi.org/project/f-yeah/



On Thu, Jun 24, 2021 at 10:07 AM Luciano Ramalho 
wrote:

> I don't think that would be a good idea since we already have
> .format() which covers that use case and is more flexible than
> f-strings (it supports positional arguments, as well as *args and
> **kwargs).
>
> I think keeping f-strings simple is a better idea.
>
> Best,
>
> Luciano
>
> On Thu, Jun 24, 2021 at 1:30 PM Eric Nieuwland 
> wrote:
> >
> > In a recent discussion with a colleague we wondered if it would be
> possible to postpone the evaluation of an f-string so we could use it like
> a regular string and .format() or ‘%’.
> >
> > I found
> https://stackoverflow.com/questions/42497625/how-to-postpone-defer-the-evaluation-of-f-strings
> and tweaked it a bit to:
> >
> > import inspect
> >
> > class DelayedFString(str):
> > def __str__(self):
> > vars = inspect.currentframe().f_back.f_globals.copy()
> > vars.update(inspect.currentframe().f_back.f_locals)
> > return self.format(**vars)
> >
> > delayed_fstring = DelayedFString("The current name is {name}")
> >
> > # use it inside a function to demonstrate it gets the scoping right
> > def new_scope():
> > names = ["foo", "bar"]
> > for name in names:
> > print(delayed_fstring)
> >
> > new_scope()
> >
> >
> > While this does what it should it is very slow.
> > So I wondered whether it would be an idea to introduce d-strings
> (delayed f-strings) and make f-strings syntactic sugar for
> >
> > f"The current name is {name}" = str(d"The current name is {name}")
> >
> >
> > And perhaps access to the variables and conversions specified in the
> d-string.
> >
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-le...@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/GT5DNA7RKRLFWE3V42OTWB7X5ER7KNSL/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Luciano Ramalho
> |  Author of Fluent Python (O'Reilly, 2015)
> | http://shop.oreilly.com/product/0636920032519.do
> |  Technical Principal at ThoughtWorks
> |  Twitter: @ramalhoorg
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/LVPDNGURA677ODMLBVUURPXKYGBKJ6A4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NVOONRQUMSBZUX4W6MTPM763DCXMOLC5/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Towards removing asynchat, asyncore and smtpd from the stdlib

2021-06-24 Thread Barry Warsaw
On Jun 23, 2021, at 16:34, Miro Hrončok  wrote:
> Yes, we have a way to check all Fedora's Python packages by reusing our 
> Python 3.10 pre-releases test-rebuild-everything mechanism, but it takes a 
> few days to finish the builds and analyze the failures. Test failures caused 
> by DeprecationWarnings are sometimes not obvious, e.g. not recognizable 
> directly from the logs -- especially if they obscure some output that's 
> checked for equality or line count (and all you get in the log is 
> AssertionError: 20 != 21), or when they exit entire pytest session without 
> any error message (arguably, that does not happen that often [1]).
> 
> When such problems are found, it takes some time to report the problem to 
> upstreams, fix the problem or workaround it (e.g. by filtering or ignoring 
> the warning, which is not always trivial, especially when it propagates 
> trough subprocess [2]).
> 
> 
> At this point of the release cycle, I'd rather recognize, triage and report 
> regressions.

Given that we have a month and change from the first release candidate, that 
should be enough time to fix any test failures due to these 
DeprecationWarnings.  I defer to the RM but Pablo already approved it. :D

https://github.com/python/cpython/pull/26882

adds import time DeprecationWarnings to asyncore, asynchat, and smtpd.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BICMIQ4ASSJTN4A5DNPFXLKSTP3DHSEV/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Delayed evaluation of f-strings?

2021-06-24 Thread Eric V. Smith
What part are you trying to delay, the expression evaluations, or the 
string building part?


There was a recent discussion on python-ideas starting at 
https://mail.python.org/archives/list/python-id...@python.org/message/LYAC7JC5253QISKDLRMUCN27GZVIUWZC/ 
that might interest you.


Eric

On 6/24/2021 5:37 AM, Eric Nieuwland wrote:
In a recent discussion with a colleague we wondered if it would be 
possible to postpone the evaluation of an f-string so we could use it 
like a regular string and .format() or ‘%’.


I found 
https://stackoverflow.com/questions/42497625/how-to-postpone-defer-the-evaluation-of-f-strings 
 
and tweaked it a bit to:


import inspect

class DelayedFString(str):
    def __str__(self):
        vars = inspect.currentframe().f_back.f_globals.copy()
vars.update(inspect.currentframe().f_back.f_locals)
        return self.format(**vars)

delayed_fstring = DelayedFString("The current name is {name}")

# use it inside a function to demonstrate it gets the scoping right
def new_scope():
    names = ["foo", "bar"]
    for name in names:
        print(delayed_fstring)

new_scope()


While this does what it should it is very slow.
So I wondered whether it would be an idea to introduce d-strings 
(delayed f-strings) and make f-strings syntactic sugar for


f"The current name is {name}" = str(d"The current name is {name}")


And perhaps access to the variables and conversions specified in the 
d-string.



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GT5DNA7RKRLFWE3V42OTWB7X5ER7KNSL/
Code of Conduct: http://python.org/psf/codeofconduct/


--
Eric V. Smith

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/O4D36DQEZU5SBIAMN227NQAR3FSVVOXR/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: Delayed evaluation of f-strings?

2021-06-24 Thread Guido van Rossum
On Thu, Jun 24, 2021 at 10:34 AM micro codery  wrote:

> As pointed out already, f-strings and format are subtly different (not
> counting that one can eval and the other cannot). Besides quoting, the
> f-sting mini language has diverged from format's
> >>> spam="Spam"
> >>> f"{spam=}"
> "spam='Spam'"
> >>> "{spam=}".format(spam=spam)
> Traceback (most recent call last):
>   File "", line 1, in 
> KeyError: 'spam='
>

Eric, what would you think of adding this feature to format()? It seems
doable (at least for keyword args -- for positional args I don't think it
makes sense).

Honestly, the rest of the discussion belongs on python-ideas.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PAWYT7P5OJXFYHHLBUEJGLDBNL4D55ZT/
Code of Conduct: http://python.org/psf/codeofconduct/