Ilya Kamenshchikov writes:
> I needed reversed(enumerate(x: list)) in my code,
def reversed_enumerated_list(l):
return zip(reversed(range(len(l)), reversed(l))
> and have discovered that it wound't work.
I wouldn't have expected it to, because enumerate's result is
unbounded. But I'm
On Sat., 28 Mar. 2020, 8:39 am Guido van Rossum, wrote:
> On Fri, Mar 27, 2020 at 3:29 PM Dennis Sweeney <
> sweeney.dennis...@gmail.com> wrote:
>
>> > If I saw that in a code review I'd flag it for non-obviousness. One
>> should
>> > use 'string != new_string' unless there is severe pressure to
On Thu, Apr 2, 2020 at 2:55 PM Pablo Galindo Salgado
wrote:
> > About the migration, can I ask who is going to (help
> to) fix projects which rely on the AST?
>
> Whoops, I send the latest email before finishing it by mistake. Here is
> the extended version of the answer:
>
> I think there is a
Sorry, I was referring to *ambiguous* grammar rules. Extract of the PEP:
"Unlike LL(1) parsers PEG-based parsers cannot be ambiguous: if a
string parses, it has exactly one valid parse tree. This means that a
PEG-based parser cannot suffer from the ambiguity problems described
in the previous
> Just to clarify, this means that 3.9 will ship with the PEG parser as default,
> right? If so, this would be a new feature, post beta. Since that is counter
> to our
> general policy, we would need to get explicit RM approval for such a change.
The idea is merging it *before beta* and make
On Apr 2, 2020, at 13:07, Pablo Galindo Salgado wrote:
>
>> Just to clarify, this means that 3.9 will ship with the PEG parser as
>> default,
>> right? If so, this would be a new feature, post beta. Since that is
>> counter to our
>> general policy, we would need to get explicit RM approval
On Thu., 2 Apr. 2020, 8:30 am Victor Stinner, wrote:
> I suggest you to wait one more week to let other people comment the
> PEP. After this delay, if you consider that the PEP is ready for
> pronouncement, you can submit it to the Steering Council, right.
>
Note that the submission to the
Wonderful news! I'm really excited to see what is coming alongside
this flexible parser.
On Thu, Apr 2, 2020 at 9:16 PM Guido van Rossum wrote:
>
> Since last fall's core sprint in London, Pablo Galindo Salgado, Lysandros
> Nikolaou and myself have been working on a new parser for CPython. We
On Thu, 2 Apr 2020 at 19:20, Guido van Rossum wrote:
>
> Since last fall's core sprint in London, Pablo Galindo Salgado, Lysandros
> Nikolaou and myself have been working on a new parser for CPython. We are now
> far enough along that we present a PEP we've written:
>
>
You can also attach gdb to a running (python) process .. but the
interpreter needs to have the symbol table (eg. not stripped).
I gave a presentation few years back on this exact topic (sorry for the
quality, I was very in-experienced).
On Thu, Apr 2, 2020 at 2:48 PM Pablo Galindo Salgado
wrote:
>
> > About the migration, can I ask who is going to (help to) fix projects
> which rely on the AST?
>
> I think you misunderstood: The AST is exactly the same as the old and the new
> parser. The only
> the thing that the new parser
On Thu, Apr 2, 2020 at 4:20 PM Nathaniel Smith wrote:
> On Thu, Apr 2, 2020 at 2:48 PM Pablo Galindo Salgado
> wrote:
> >
> > > About the migration, can I ask who is going to (help to) fix projects
> > which rely on the AST?
> >
> > I think you misunderstood: The AST is exactly the same as the
These are good news. I think the new parser is indeed both simpler and more
flexible - great!
--
Ivan
On Thu, 2 Apr 2020 at 19:19, Guido van Rossum wrote:
> Since last fall's core sprint in London, Pablo Galindo Salgado, Lysandros
> Nikolaou and myself have been working on a new parser for
On Thu, Apr 2, 2020 at 12:43 PM Paul Moore wrote:
> On Thu, 2 Apr 2020 at 19:20, Guido van Rossum wrote:
> >
> > Since last fall's core sprint in London, Pablo Galindo Salgado,
> Lysandros Nikolaou and myself have been working on a new parser for
> CPython. We are now far enough along that we
On 3/04/20 10:33 am, Victor Stinner wrote:
I also like the fact that PEG is deterministic, whereas
LL(1) parsers are not.
Where do you get that LL(1) parsers are not deterministic?
That's news to me!
--
Greg
___
Python-Dev mailing list --
> About the migration, can I ask who is going to (help to) fix projects
which rely on the AST?
I think you misunderstood: The AST is exactly the same as the old and the new
parser. The only
the thing that the new parser does is not generate an immediate CST (Concrete
Syntax Tree) and that
is
On Thu, Apr 2, 2020 at 1:21 PM Barry Warsaw wrote:
> On Apr 2, 2020, at 13:07, Pablo Galindo Salgado
> wrote:
> >
> >> Just to clarify, this means that 3.9 will ship with the PEG parser as
> default,
> >> right? If so, this would be a new feature, post beta. Since that is
> counter to our
>
Great to see this new work pay off!
On Apr 2, 2020, at 11:10, Guido van Rossum wrote:
> 2. After Python 3.9 Beta 1 the default parser will be the new parser.
Just to clarify, this means that 3.9 will ship with the PEG parser as default,
right? If so, this would be a new feature, post beta.
> About the migration, can I ask who is going to (help
to) fix projects which rely on the AST?
Whoops, I send the latest email before finishing it by mistake. Here is the
extended version of the answer:
I think there is a misunderstanding here: The new parser generates the same AST
as the old
Hi,
It's great to see that you finally managed to come up with a PEP, this
work becomes concrete: congrats!
I started to read the PEP, and it's really well written! I heard that
LL(1) parsers have limits, but this PEP explains very well that the
current Python grammar was already "hacked" to
On 3/04/20 7:10 am, Guido van Rossum wrote:
Since last fall's core sprint in London, Pablo Galindo Salgado,
Lysandros Nikolaou and myself have been working on a new parser for
CPython. We are now far enough along that we present a PEP we've written:
https://www.python.org/dev/peps/pep-0617/
On Thu, Apr 02, 2020 at 05:17:31PM -0700, Guido van Rossum wrote:
> On Thu, Apr 2, 2020 at 4:20 PM Nathaniel Smith wrote:
>
> If the AST is supposed to be the same, then would it make sense to
> temporarily – maybe just during the alpha/beta period – always run
> *both* parsers and
On Thu, Apr 02, 2020 at 08:57:30PM -0700, Guido van Rossum wrote:
> On Thu, Apr 2, 2020 at 7:55 PM Matt Billenstein wrote:
>
> Even just running it in a dev build against the corpus of the top few
> thousand packages on pypi might give enough confidence -- I had a script
> to
Le ven. 3 avr. 2020 à 02:58, Greg Ewing a
écrit :
> On 3/04/20 10:33 am, Victor Stinner wrote:
> > I also like the fact that PEG is deterministic, whereas
> > LL(1) parsers are not.
>
> Where do you get that LL(1) parsers are not deterministic?
> That's news to me!
On Thu, Apr 2, 2020 at 6:15
On 3/04/20 3:22 pm, Guido van Rossum wrote:
This allows more freedom in designing a grammar.
For example, it would let a language designer solve the "dangling else"
problem from the Wikipedia page, by writing the form including the
"else" clause first .
I'm inclined to think that such
On Thu, Apr 2, 2020 at 7:55 PM Matt Billenstein wrote:
> On Thu, Apr 02, 2020 at 05:17:31PM -0700, Guido van Rossum wrote:
> > On Thu, Apr 2, 2020 at 4:20 PM Nathaniel Smith wrote:
> >
> > If the AST is supposed to be the same, then would it make sense to
> > temporarily – maybe just
On 3/04/20 2:13 pm, Victor Stinner wrote:
"Unlike LL(1) parsers PEG-based parsers cannot be ambiguous: if a
string parses, it has exactly one valid parse tree. This means that a
PEG-based parser cannot suffer from the ambiguity problems described
in the previous section."
That paragraph seems
Re: st...@pearwood.info
> It isn't really well-defined, since enumerate can operate on infinite
> iterators, and you cannot reverse an infinite stream.
It is well defined on any iterable that itself is reversible and has
defined length. For standard types that's lists, strings, dictionary
One potentially serious question: what should `enumerate.__reversed__`
> do when given a starting value?
> reversed(enumerate('abc', 1))
> Should that yield...?
> # treat the start value as a start value
> (1, 'c'), (0, 'b'), (-1, 'a')
> # treat the start value as an end value
>
Since last fall's core sprint in London, Pablo Galindo Salgado, Lysandros
Nikolaou and myself have been working on a new parser for CPython. We are
now far enough along that we present a PEP we've written:
https://www.python.org/dev/peps/pep-0617/
Hopefully the PEP speaks for itself. We are
On 2020-03-24 16:31, Mark Shannon wrote:
Hi,
As an experiment, I thought I would try moving the thread state (what
you get from _PyThreadState_GET() ) to TLS.
https://github.com/python/cpython/compare/master...markshannon:threadstate_in_tls
It works, passing all the tests, and seems
31 matches
Mail list logo
