Another point in favour of always-reserved keywords is that they
make life a lot easier for syntax highlighters.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python
On 7/04/20 6:54 am, Guido van Rossum wrote:
I'm not sure that that was the conclusion. At the time the point was
that we *wanted* all keywords to be reserved everywhere, an `as` was an
ugly exception to that rule, which we got rid of as soon as we could --
not because it was a bad idea but bec
On 7/04/20 5:43 am, Guido van Rossum wrote:
The biggest difference is that the `|` operator is no longer
symmetrical (since if you have alternatives `A | B`, and both match at
some point in the input, PEG reports A, while the old generator would
reject the grammar as being ambiguous.
I'm stil
Looking over the commit history for the PR (
https://github.com/python/cpython/pull/18239/commits), it looks like that
specific Azure Pipelines failure did not start occurring until
upstream/master was merged into the PR branch (
https://github.com/python/cpython/pull/18239/commits/13d3742fd897e1ea
Hm, looking over the diff from a different perspective I think I have
changed a few `__class_getitem__` methods that I shouldn't have. I'll see
if that fixes it later tonight.
On Mon, Apr 6, 2020 at 7:23 PM Ethan Smith wrote:
> (Trusty assistant reporting in) I should also note that further up t
(Trusty assistant reporting in) I should also note that further up the
output there is a FileNotFoundError for sqlite3.dll, perhaps it isn't built
or is in the wrong place?
Ethan
On Mon, Apr 6, 2020, 7:19 PM Guido van Rossum wrote:
> I have a large PR (https://github.com/python/cpython/pull/18
I have a large PR (https://github.com/python/cpython/pull/18239, for PEP
585) that's failing in the Azures pipeline on Win32 and Win64 only. My
trusty assistant who has a Windows laptop couldn't reproduce the failure.
Can I buy a hint from someone? Steve?
The relevant failure output is:
=
After 30 years am I not allowed to take new information into account and
consider a change of heart? :-)
On Mon, Apr 6, 2020 at 6:21 PM Steven D'Aprano wrote:
> On Mon, Apr 06, 2020 at 11:54:54AM -0700, Guido van Rossum wrote:
>
> > (In an early version of the PEG parser, all keywords were
> > c
On Mon, Apr 06, 2020 at 11:54:54AM -0700, Guido van Rossum wrote:
> (In an early version of the PEG parser, all keywords were
> context-sensitive, and there were only very few places in the grammar where
> this required us to insert negative lookaheads to make edge cases parse
> correctly. The res
On Mon, Apr 6, 2020 at 8:04 PM Guido van Rossum wrote:
> On Mon, Apr 6, 2020 at 11:36 AM Steven D'Aprano
> wrote:
>
>>
>> Personally, I would not like to have to explain to newcomers why `match`
>> is a keyword but you can still use it as a function or variable, but not
>> other keywords like `r
On 06/04/2020 20:41, Musbur wrote:
Hi Nick, thanks for forwarding the post. BTW, I've posted a complete,
self-contained example on stackoverflow (which also received zero
attention so far):
After that comment I'm not particularly inclined to solve your problem
for you, so I'll just say that yo
On Mon, 6 Apr 2020 08:32:34 +1000
Nick Coghlan wrote:
> Hi Musbur,
>
> While python-dev is specifically for core development, the "specific
> interest group" mailing lists are for both change proposals and
> existing usage questions.
>
> I've cc'ed capi-sig on this reply.
Hi Nick, thanks for f
On Tue, Apr 7, 2020 at 5:03 AM Guido van Rossum wrote:
>
> On Mon, Apr 6, 2020 at 11:36 AM Steven D'Aprano wrote:
>> Personally, I would not like to have to explain to newcomers why `match`
>> is a keyword but you can still use it as a function or variable, but not
>> other keywords like `raise`,
On Mon, Apr 6, 2020 at 11:36 AM Steven D'Aprano wrote:
> On Mon, Apr 06, 2020 at 10:43:11AM -0700, Guido van Rossum wrote:
>
> > I've been toying with the idea of introducing a "match" statement
> > similar to Scala's match expression by making "match" a keyword only when
> > followed by an expre
On Mon, Apr 06, 2020 at 10:43:11AM -0700, Guido van Rossum wrote:
> I've been toying with the idea of introducing a "match" statement
> similar to Scala's match expression by making "match" a keyword only when
> followed by an expression and a colon.)
Didn't we conclude from `as` that having cont
On Mon, Apr 6, 2020 at 5:18 AM Jeff Allen wrote:
> The PEP gives a good exposition of the problem and proposed solution,
> thanks.
>
> If I understand correctly, the proposal is that the PEG grammar should
> become the definitive grammar for Python at some point, probably for Python
> 3.10, so it
On Mon, Apr 6, 2020 at 4:03 AM Fabio Zadrozny wrote:
> I think using a PEG parser is interesting, but I do have some questions
> related to what's to expect in the future for other people which have to
> follow the Python grammar, so, can you shed some light on this?
>
> Does that mean that the g
Thanks for the feedback, everyone. I'm satisfied that the bytecodes are
stable enough to work for my purpose. Now I just have to find time to work
on it around my schoolwork.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an ema
Greetings,
2.7.18 release candidate 1, a testing release for the last release of the
Python 2.7 series, is now available for download. The CPython core developers
stopped applying routine bugfixes to the 2.7 branch on January 1. 2.7.18 will
includes fixes that were made between the release of 2.
The PEP gives a good exposition of the problem and proposed solution,
thanks.
If I understand correctly, the proposal is that the PEG grammar should
become the definitive grammar for Python at some point, probably for
Python 3.10, so it may evolve without the LL(1) restrictions. I'd like
to r
Le dim. 5 avr. 2020 à 23:07, Skip Montanaro a écrit :
> I'm trying it the simplest way I can think of. Registers are exactly
> like local variables, so SETLOCAL Py_XDECREFs whatever is already
> there before overwriting it with a new value. At the end of
> _PyEval_EvalFrameDefault if the code obje
BTW, so that we don't have to completely retrace our steps, this topic
was also discussed in depth on Python-Ideas in May 2014:
https://mail.python.org/archives/list/python-id...@python.org/thread/X6VCB2E4EHOLUWHO42FYUT6VDAFNUHJF/
--Ned.
On 4/6/20 6:56 AM, Ned Batchelder wrote:
On 4/6/20 5:41
On Thu, Apr 2, 2020 at 3: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 are
> now far enough along that we present a PEP we've written:
>
> https://www.python.org/dev
On 4/6/20 5:41 AM, Mark Shannon wrote:
Hi,
On 05/04/2020 12:47 pm, Ned Batchelder wrote:
On 4/3/20 11:13 AM, joannah nanjekye wrote:
Hey all,
From my CS theory, a control flow graph models a program flow and
one of its main characteristics is it has one entry and exit point.
IIRC, CPython’s
Hi,
On 05/04/2020 12:47 pm, Ned Batchelder wrote:
On 4/3/20 11:13 AM, joannah nanjekye wrote:
Hey all,
From my CS theory, a control flow graph models a program flow and one
of its main characteristics is it has one entry and exit point. IIRC,
CPython’s compilation process involves generation
06.04.20 06:48, Jonathan Goble пише:
My question is, are the opcodes guaranteed stable across the lifetime of
a single 3.x release? In other words, are they guaranteed to not change
values or semantics between 3.x.y and 3.x.(y+1)? Reading through the
list of opcodes in the dis documentation, it
On Mon, 6 Apr 2020, 06:30 Brandt Bucher, wrote:
> > The best way to look at this is to consider how long a .pyc file is
> valid. They're currently named something like
> __pycache__/modulename.cpython-38.pyc which is a fairly clear indication
> that the cached compiled module should be valid for
27 matches
Mail list logo
