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

[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

[Python-Dev] Re: On the migration from master to main

2021-05-10 Thread Martin (gzlist) via Python-Dev
On Tue, 23 Mar 2021 at 21:39, Python Steering Council wrote: > > This isn’t happening because GitHub/Microsoft made a political decision. It’s > happening because it is incredibly easy to make this move, many projects have > already done this, and it reflects badly on any project not making this

[Python-Dev] Re: Integer concatenation to byte string

2021-03-05 Thread Martin (gzlist) via Python-Dev
On Tue, 2 Mar 2021 at 21:44, Memz wrote: > > foo+= 255 # Works the same as > bytesvariable+=b"ÿ" foo = b"%b%d" % (foo, 255) > foo+= a"\x255\x00" # Concatenation with itself foo = b"%b%b" % (foo, foo) See PEP461: Adding % formatting to bytes an

[Python-Dev] Re: PEP 638: Syntactic macros

2020-10-19 Thread Martin (gzlist) via Python-Dev
On Fri, 16 Oct 2020 at 23:22, Guido van Rossum wrote: > > Dima, > > Do you have a link to "babel macros"? Searching for that brought up several > different things; not being a frequent JS user I don't know how to filter > these. These links should help: https://babeljs.io/blog/2017/09/11/zero-

[Python-Dev] Re: Something wrong with the bug tracker?

2019-12-22 Thread Martin (gzlist) via Python-Dev
Logging in with openid using launchpad just worked for me, so transient or related to google's openid support presumably. Martin On Sun, 22 Dec 2019 at 15:13, Mark Shannon wrote: > > Hi, > > For some reason I can't log into the bug tracker with Google. > I just get the error message: > > """ > A

Re: [Python-Dev] Replacement for array.array('u')?

2019-03-25 Thread Martin (gzlist) via Python-Dev
On Fri, 22 Mar 2019 at 16:12, Steve Dower wrote: > > On 22Mar2019 0433, Antoine Pitrou wrote: > > The question is: why would you use a array.array() with a Windows C API? > > I started replying to this with a whole lot of examples, and eventually > convinced myself that you wouldn't (or shouldn't)

Re: [Python-Dev] Evil reference cycles caused Exception.__traceback__

2017-09-18 Thread Martin (gzlist) via Python-Dev
Thanks for working on this and writing up the details Victor. For those confused about why this matters, routinely having every object in your application participating in one (or more) giant reference cycles makes reasoning about and fixing resource issues very difficult. For instance, a while b

Re: [Python-Dev] PEP 538 (review round 2): Coercing the legacy C locale to a UTF-8 based locale

2017-06-12 Thread Martin (gzlist) via Python-Dev
Thanks for replying to my points! On 12/06/2017, Nick Coghlan wrote: > > `PYTHONIOENCODING=:strict` remains the preferred way of forcing strict > encoding checks on the standard streams, regardless of locale. Then the user of my script has to care that it's written in Python and set that specifi

Re: [Python-Dev] Handle errors in cleanup code

2017-06-12 Thread Martin (gzlist) via Python-Dev
On 12/06/2017, Serhiy Storchaka wrote: > > But if an error is raised when execute undo_something(), it replaces the > original exception which become chaining as the __context__ attribute. > The problem is that this can change the type of the exception. If > do_something_other() raises SystemExit

Re: [Python-Dev] PEP 538 (review round 2): Coercing the legacy C locale to a UTF-8 based locale

2017-06-11 Thread Martin (gzlist) via Python-Dev
On 09/05/2017, Nick Coghlan wrote: > > Enough changes have accumulated in PEP 538 since the start of the > previous thread that it seems sensible to me to start a new thread > specifically covering the current design (which aims to address all > the concerns raised in the previous thread). > > I h