On Mon, May 30, 2022 at 12:54 PM Steve Dower wrote:
> I prefer separate header files, provided people outside of core always
> have one (presumably "Python.h") that should be included first and
> includes enough info to check which headers will be available (i.e. the
> version defs).
>
The idea
I prefer separate header files, provided people outside of core always
have one (presumably "Python.h") that should be included first and
includes enough info to check which headers will be available (i.e. the
version defs).
Modifying preprocessor definitions for different Python versions, or
I would love to see header files used for this -- while I know there is a
long tradition of feature-flags that must be #defined by the user before
#including a header in order to affect what the header exports (or not!),
30 years later I still find that approach pretty unintuitive.
But yes, it's g
We discussed having leading underscores for this API tier, and it was decided
that a leading underscore was preferred.
This did start a discussion, though, about whether we should control API
access/opt-in via `#include` by having `.h` files that convey what API the user
is opting into, or use
Hi Pablo, could you clarify please? Is that on the main branch, or would
you be willing to share the code?
On 30/05/2022 16:23, Pablo Galindo Salgado wrote:
There is no *public* one but there is a private one accesible from
Python I added for testing purposes.
On Mon, 30 May 2022, 15:17 Victo
Is on the main branch but as I mentioned is **exclusively** for internal
consumption:
https://github.com/python/cpython/blob/8136606769661c103c46d142e52ec88803f6/Lib/tokenize.py#L685
On Mon, 30 May 2022 at 17:37, Jack wrote:
> Hi Pablo, could you clarify please? Is that on the main branch,
There is no *public* one but there is a private one accesible from Python I
added for testing purposes.
On Mon, 30 May 2022, 15:17 Victor Stinner, wrote:
> On Mon, May 30, 2022 at 1:40 AM Eric V. Smith wrote:
> > python -m tokenize < file-to-parse.py
> >
> > See the comment at the top of tokeni
On Mon, May 30, 2022 at 1:40 AM Eric V. Smith wrote:
> python -m tokenize < file-to-parse.py
>
> See the comment at the top of tokenize.py. IIRC, it re-implements the
> tokenizer, it does not call the one used for python code.
Ah right, I would be surprised that there would be a public Python API
Thank you to everyone who responded, it is now clear to me that this
genuinely is a feature, not a bug or limitation of the parser or lexer.
And that there is code relying on that behaviour, including in the
stdlib, so we shouldn't change it even if we could.
--
Steve
