[Python-Dev] Re: Regressions caused the recent work on ceval.c and frame objects

> Will all packages that use Cython have to upgrade Cython to work with 3.10? For this particular issue you'll only have to upgrade if you use "profiling" (I doubt that many packages routinely build with Cython profiling turned on). However, it's possible there are other 3.10 bugfixes in Cython

[Python-Dev] Re: Regressions caused the recent work on ceval.c and frame objects

On 20. 09. 21 7:40, Christopher Barker wrote: Will all packages that use Cython have to upgrade Cython to work with 3.10? I am not sure if all, but many will do. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ Python-Dev mailing list --

[Python-Dev] Re: f-strings in the grammar

20.09.21 14:18, Pablo Galindo Salgado пише: > * The parser will likely have "\n" characters and backslashes in > f-strings expressions, which currently is impossible: What about characters "\x7b", "\x7d", "\x5c", etc? What about newlines in single quotes? Currently this works: f'''{1 + 2}'''

[Python-Dev] Re: Regressions caused the recent work on ceval.c and frame objects

msgpack 1.0.2 sdist includes c++ code generated by Cython 0.29.21 released at 2020-07-09. Python 3.10 can build it without any source modifications. So I don't expect Python 3.10 requires re-generation for most Cython users. Regards, On Mon, Sep 20, 2021 at 4:11 PM wrote: > > > Will all

[Python-Dev] Re: f-strings in the grammar

> > What about characters "\x7b", "\x7d", "\x5c", etc? > What about newlines in single quotes? Currently this works: This is from the current branch: >>> f"ble { '\x7b' }" 'ble {' >>> f"{1 + ... 2}" '3' >>> f'{1 + ... 2}' '3' On Mon, 20 Sept 2021 at 13:52, Serhiy Storchaka wrote: >

[Python-Dev] Re: f-strings in the grammar

On 9/20/2021 8:46 AM, Serhiy Storchaka wrote: 20.09.21 14:18, Pablo Galindo Salgado пише: * The parser will likely have "\n" characters and backslashes in f-strings expressions, which currently is impossible: What about characters "\x7b", "\x7d", "\x5c", etc? What about newlines in single

[Python-Dev] Re: f-strings in the grammar

Thanks a lot, Eric for your message! I actually share some of these worries myself and that's why I wanted to have a bigger conversation. I wanted to also make clear that the change doesn't force us to do *everything*. This means that we can absolutely have some of the improvements but not others

[Python-Dev] Re: f-strings in the grammar

On 9/20/2021 7:18 AM, Pablo Galindo Salgado wrote: there are some interesting things we **could** (emphasis on could) get out of this and I wanted to discuss what people think about them. * The parser will allow nesting quote characters. This means that we **could** allow reusing the same

[Python-Dev] Re: f-strings in the grammar

On 9/20/2021 11:21 AM, Terry Reedy wrote: On 9/20/2021 8:46 AM, Serhiy Storchaka wrote: 20.09.21 14:18, Pablo Galindo Salgado пише: * The parser will likely have "\n" characters and backslashes in f-strings expressions, which currently is impossible: What about characters "\x7b", "\x7d",

[Python-Dev] f-strings in the grammar

Hi, I have started a project to move the parsing off-strings to the parser and the grammar. Appart from some maintenance improvements (we can drop a considerable amount of hand-written code), there are some interesting things we **could** (emphasis on could) get out of this and I wanted to

[Python-Dev] Re: f-strings in the grammar

On 9/20/2021 11:19 AM, Terry Reedy wrote: On 9/20/2021 7:18 AM, Pablo Galindo Salgado wrote: there are some interesting things we **could** (emphasis on could) get out of this and I wanted to discuss what people think about them. * The parser will allow nesting quote characters. This means

[Python-Dev] Re: f-strings in the grammar

The current restrictions will also confuse some users (e.g. those used to bash, and IIRC JS, where the rules are similar as what Pablo is proposing). On Mon, Sep 20, 2021 at 8:24 AM Terry Reedy wrote: > On 9/20/2021 7:18 AM, Pablo Galindo Salgado wrote: > > > there are some interesting things

[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

On Sun, Sep 19, 2021 at 8:15 AM Steve Holden wrote: > I understood that _iterables_ are required to have an __iter__ method, not > iterators. > > Therefore, are we simply discussing whether all iterators should be > iterable? > At this point it's more about how to document this. > At the

[Python-Dev] Re: f-strings in the grammar

I don't think the python syntax should be beholden to syntax highlighting tools, eventually some syntax feature that PEG enables will require every parser or highlighter to switch to a similar or more powerful parse tool ___ Python-Dev mailing list --

[Python-Dev] Re: f-strings in the grammar

On 20 Sep 2021, at 13:18, Pablo Galindo Salgado mailto:pablog...@gmail.com>> wrote: We are doing this work in this branch: https://github.com/we-like-parsers/cpython/blob/fstring-grammar That link is broken. Assuming you mean https://github.com/we-like-parsers/cpython/tree/fstring-grammar?

[Python-Dev] Re: f-strings in the grammar

On Mon, Sep 20, 2021 at 1:07 PM Patrick Reader <_...@pxeger.com> wrote: > > The current restrictions will also confuse some users (e.g. those used > to bash, and IIRC JS, where the rules are similar as what Pablo is > proposing). > > -- > > --Guido van Rossum (python.org/~guido

[Python-Dev] Re: f-strings in the grammar

>> But I also think this means we definitely have to get a parser module What is in this context a "parse" module? Because that will massively change depending who you ask. We already expose APIs that return AST objects that can be used for all sort of things and a tokenizer module that exposes

[Python-Dev] Re: f-strings in the grammar

Eric V. Smith writes: > >> But this does not: > >> > >> f'{1 + > >> 2}' > > > > The later is an error with or without the 'f' prefix and I think that > > this should continue to be the case. > > > The thought is that anything that's within braces {} and is a valid > expression should

[Python-Dev] Re: f-strings in the grammar

On Mon, Sep 20, 2021 at 8:58 AM Thomas Grainger wrote: > I don't think the python syntax should be beholden to syntax highlighting > tools, eventually some syntax feature that PEG enables will require every > parser or highlighter to switch to a similar or more powerful parse tool > But that's

[Python-Dev] Re: f-strings in the grammar

I know I'm strongly -1 on allowing much more than currently exists for f-strings. For basically the same reason Stephen explains. Newlines inside braces, for example, go way too far away from readability. Nested expressions also feel like an attractive nuisance. I use f-strings all the time, but

[Python-Dev] Re: f-strings in the grammar

[Stephen J. Turnbull] > Is this syntax useful? Or is it just a variant of purity trying to > escape Pandora's virtualbox? I mean, am I going to see it often > enough to get used to it? Or am I going to WTF at it for the rest of > my life? > I don't know about the line breaks, but in recent

[Python-Dev] Re: f-strings in the grammar

Guido van Rossum writes: > I don't know about the line breaks, but in recent weeks I've found myself > more than once having to remind myself that inside interpolations, you must > use the other type of quote. My earlier remarks were specifically directed to line breaks. I see the point, but

[Python-Dev] Re: f-strings in the grammar

I just want to say that I am very excited to see where this goes. As an author of a package that tries to recreate compiled f-strings at runtime, they are a hard thing to generate given the current tools within Python. On Mon, Sep 20, 2021 at 4:23 AM Pablo Galindo Salgado wrote: > > Tell me

[Python-Dev] Re: f-strings in the grammar

On 9/20/2021 11:48 AM, Eric V. Smith wrote: When I initially wrote f-strings, it was an explicit design goal to be just like existing strings, but with a new prefix. That's why there are all of the machinations in the parser for scanning within f-strings: the parser had already done its

[Python-Dev] Re: f-strings in the grammar

> The current restrictions will also confuse some users (e.g. those used to > bash, and IIRC JS, where the rules are similar as what Pablo is proposing). > -- > --Guido van Rossum (python.org/~guido ) WRT the similar syntax in bash (and similar shells), there are two