> 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 any CPython 3.8.x release.
Perhaps an even
On Mon, Apr 6, 2020 at 12:02 AM Chris Angelico wrote:
> On Mon, Apr 6, 2020 at 1:53 PM Jonathan Goble wrote:
> >
> > I'm getting ready to get back into an old personal project with some new
> ideas. Before I do, I need to ask a question regarding the stability of
> CPython bytecode. Before you
On Mon, Apr 6, 2020 at 1:53 PM Jonathan Goble wrote:
>
> I'm getting ready to get back into an old personal project with some new
> ideas. Before I do, I need to ask a question regarding the stability of
> CPython bytecode. Before you say it, I am well aware and fully understand
> that the
I'm getting ready to get back into an old personal project with some new
ideas. Before I do, I need to ask a question regarding the stability of
CPython bytecode. Before you say it, I am well aware and fully understand
that the opcodes may change in value and semantics between 3.x and 3.(x+1)
On Sun, Apr 5, 2020 at 5:16 PM Greg Ewing
wrote:
> On 6/04/20 4:48 am, Guido van Rossum wrote:
> > There's no need to worry about this: in almost all cases the error
> > indicator points to the same spot in the source code as with the old
> > parser.
>
> I'm curious about how that works. From
For posterity, just recording best guesses for the other mysteries left hanging:
- PYTHONTRACEMALLOC didn't work for you because Victor's traceback
showed that Py_FinalizeEx was executing _PyImport_Fini,, one statement
_after_ it disabled tracemalloc via _PyTraceMalloc_Fini.
- The address passed
On 6/04/20 4:48 am, Guido van Rossum wrote:
There's no need to worry about this: in almost all cases the error
indicator points to the same spot in the source code as with the old
parser.
I'm curious about how that works. From the description in the PEP,
it seems that none of the individual
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.
Cheers,
Nick.
On Sat., 4 Apr. 2020, 2:02 am Musbur, wrote:
> Hello,
>
> (I've asked
> It seems like your Python changes use Py_False "somewhere" without
> Py_INCREF(Py_False).
> Maybe it's COMPARE_OP_REG() which calls SETLOCAL(dst, False).
Yes, this was the problem. Thanks for the fix. Too much blind
adherence on my part to the existing COMPARE_OP logic. I've even
written
The tl;dr is that actions specified in the grammar are specific to the
target language. So if you want to use the pegen tool to generate both
Python and C code for the same grammar, you would need two grammar files
with the same grammar but different actions. Since our goal here is just to
> The only thing I'm missing from the PEP is more detail about how the
cross-language nature of the parser actions are handled.
Expanded the "actions" section in the PEP here:
https://github.com/python/peps/pull/1357
___
Python-Dev mailing list --
Le dim. 5 avr. 2020 à 04:02, Skip Montanaro a écrit :
> The command is
>
> % PYTHONTRACEMALLOC=5 ./python ./Tools/scripts/run_tests.py -R
> 5:50:reflog.txt test_rattlesnake
> (...)
> FWIW, the register branch of my CPython fork:
>
> https://github.com/smontanaro/cpython/tree/register
gdb
> On 6/04/20 2:08 am, Jelle Zijlstra wrote:
> > The current CPython parser usually just produces "SyntaxError: invalid
> > syntax" for any error, while other languages that I work with usually
> > say something more precise like 'expected x, got y'. What will the error
> > messages in the PEG
On 6/04/20 2:08 am, Jelle Zijlstra wrote:
The current CPython parser usually just produces "SyntaxError: invalid
syntax" for any error, while other languages that I work with usually
say something more precise like 'expected x, got y'. What will the error
messages in the PEG parser look like?
El jue., 2 abr. 2020 a las 11:19, Guido van Rossum ()
escribió:
> 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:
>
>
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 of a control flow graph.
Contrary to peephole
Hi Leandro, it seems that your email is probably more about how to use the
existing PyEval_SetTrace API, not about developing or changing Python
itself. May I direct you to the "Got a Python problem or question?" section
from https://www.python.org/about/help/ web page, where you are likely to
get
17 matches
Mail list logo
