What happened to this SC decision (move to Discourse)? People started
again to write on python-dev. So what's going on?
Should I reply on python-dev? Ask to move to Discourse?
Should we *close* the python-dev mailing list?
Victor
___
Python-Dev
Alexei is about about https://github.com/python/cpython/issues/96853
I suggest discussing the issue there.
Victor
On Thu, Oct 6, 2022 at 9:54 PM wrote:
>
> Hi Python team
>
> Is any plan to try and fix memory leaks when embedding Python in a C/C++
> application?
>
> Thanks in advance,
>
On Thu, Jun 16, 2022 at 7:54 PM Christian Heimes wrote:
> What Victor means that we would like to have clear instructions how to
> reproduce the problem ourselves. Could you please provide step by step
> instructions how I could set up a build environment on a X86_64 PC with
> a standard Linux
On Thu, Jun 16, 2022 at 4:29 PM Xavier de Gaye wrote:
> A Google search on "andoid x86_64" gives about 10,900,000 results, showing
> that cross-compiling is quite common for the case where the build system and
> the host system have the same PLATFORM_TRIPLET as when building android
> x86_64
Hi,
While this problem is causing you a lot of troubles, I never had to
cross compile Python, and I guess that it's the case for most people.
Changing the Python build system and distutils is stressful since it
can break Python for the majority of users, rather than leaving the
minority of users
On Mon, Jun 6, 2022 at 4:35 PM Gabriele wrote:
> The austinp variant is a variant of Austin
> (https://github.com/P403n1x87/austin) for Linux that uses ptrace to
> seize and interrupt/continue threads to capture native stack traces
> using libunwind. During testing, I have discovered that there
Hi,
Side note: it would be nice to add "typing: " prefix or mention "type
annotation" or "type check" in the title of PEPs which are about that.
Just from the PEP title, it's hard *for me* to guess that it's about
type annotations.
Examples of other PEP titles which confused me:
PEP 612 –
Hi,
On buildbots, it's common that we get at least one multiprocessing
test failure per week. While I just reported a new one, I wanted to
add a "expert-multiprocessing" label, but it didn't exist. I just
created the label :-)
https://github.com/python/cpython/labels/expert-multiprocessing
I
anch, 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 Vic
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
Hi,
Please report Python issues to the GitHub project:
https://github.com/python/cpython/issues/
The OpenBSD operating system is currently not supported by Python, so
don't expect a quick feedback:
https://peps.python.org/pep-0011/
A few years ago, I tried to provide best effort support for
On Mon, May 16, 2022 at 2:11 PM Antoine Pitrou wrote:
> > PyUnicodeBuilder_Init();
> >
> > // Overallocation is more efficient if the final length is unknown
> > PyUnicodeBuilder_EnableOverallocation();
> > PyUnicodeBuilder_WriteStr(, key);
> >
On Mon, May 16, 2022 at 12:51 PM wrote:
>
> Victor Stinner wrote:
> > On Mon, May 16, 2022 at 11:40 AM dw-...@d-woods.co.uk wrote:
> > > Cython used the private _PyUnicodeWriter API (and stopped using it on
> > > Py3.11 when it was hidden more thoroughly)
>
On Mon, May 16, 2022 at 11:40 AM wrote:
> Cython used the private _PyUnicodeWriter API (and stopped using it on Py3.11
> when it was hidden more thoroughly)
I'm not aware of any change in the the private _PyUnicodeWriter API in
Python 3.11. Is it just that Cython no longer wants to use private
Hi,
I propose adding a new C API to "build an Unicode string". What do you
think? Would it be efficient with any possible Unicode string storage
and any Python implementation?
PyPy has an UnicodeBuilder type in Python, but here I only propose C
API. Later, if needed, it would be easy to add a
According to my notes, the summary is generated by this Python script:
https://github.com/psf/bpo-tracker-cpython/blob/master/scripts/roundup-summary
But I don't know what runs this script once a week.
Victor
On Fri, May 13, 2022 at 8:56 PM Brett Cannon wrote:
>
> Can we shut this down or
On Tue, May 10, 2022 at 7:18 PM Guido van Rossum wrote:
> Shouldn't we wean our internal tools off this obsolete version of distutils
> too, rather than just move it around?
Here is a first PR to build the test C++ extension with setuptools in
test_cppext:
On Tue, May 10, 2022 at 6:16 PM Steve Dower wrote:
> I agree. The internal tools that use it are all in our Tools directory,
> so we can move distutils there and explicitly add an import path to
> locate it. No need to keep it in the stdlib (Lib/) at all.
>
> Migrating to Makefile builds is
On Tue, May 10, 2022 at 5:33 PM Christian Heimes wrote:
> We can easily take care of test_cppext and add the build step to
> Makefile.
What matters in test_cppext is that using the Python C API in C++ does
not emit compiler warnings, so it uses -Werror. Since this test is
very new, I would
On Tue, May 10, 2022 at 11:28 AM Christian Heimes wrote:
> > Right now, Python still uses distutils internally for multiple use
> > cases. I propose to start with renaming the distutils package to
> > _distutils in the stdlib:
> >
> > * https://github.com/python/cpython/issues/92584
> > *
Hi,
Two years ago, PEP 632 "Deprecate distutils module" was accepted: the
distutils package was deprecated in Python 3.10 and scheduled for
removal in Python 3.12. Questions.
* Is the Python ecosystem ready for the distutils removal? How many
projects are expected to be broken by this removal?
Hi,
I added the -P command line option and the PYTHONSAFEPATH=1
environment variable to Python 3.11 beta 1 to not prepend an "unsafe
path" to sys.path such as the script's directory or the current
directory:
https://docs.python.org/dev/using/cmdline.html#cmdoption-P
Example:
--
$ echo
On Fri, May 6, 2022 at 2:14 PM Pablo Galindo Salgado
wrote:
> Today we need to start the release of Python 3.11 beta 1. Currently, we have
> the following blockers:
>
> * https://github.com/python/cpython/issues/91162 (was deferred blocker - but
> all deferred blockers are bumped to release
porting the site module,
> maybe a different option can be added, no? Adding -P doesn't prevent
> that. But it seems like use cases are different enough to justify two
> options, no?
>
> Victor
>
>
> On Tue, Apr 26, 2022 at 11:52 PM Victor Stinner wrote:
> > The only purpose of pro
Every day, I unsubscribe from many issues and pull requests to reduce
the number of emails to move it below my acceptable threshold. For
example, for me, 20 new discussions per day is acceptable, whereas 100
is not.
I prefer to focus on small number of things and follow them closely.
Victor
Hi,
I updated my PR https://github.com/python/cpython/pull/31542 and I
plan to merge it soon.
It seems like most people need and like this feature.
About the feature name, nobody liked the "add_path0" name which is
misleading: "path0" is not easy to get, and the path is prepended, not
added.
I
the memory. But maybe tomorrow, the implementation
will deeply change and will need to modify the memory. In C, using "const"
(for something other than const char*) is just not convenient.
Victor
On Tue, May 3, 2022 at 9:22 AM Antoine Pitrou wrote:
> On Mon, 2 May 2022 15:21:24 +0200
&
Hi,
I merged the best basic tests to make sure that using the Python C API in
C++ does not emit compiler warnings:
* Code: https://github.com/python/cpython/blob/main/Lib/test/_testcppext.cpp
* Test: https://github.com/python/cpython/blob/main/Lib/test/test_cppext.py
The code is only built to
On Fri, Apr 29, 2022 at 8:12 PM Python tracker
wrote:
> ACTIVITY SUMMARY (2022-04-22 - 2022-04-29)
> Python tracker at https://bugs.python.org/
>
> To view or respond to any of the issues listed below, click on the issue.
> Do NOT respond to this message.
>
> Issues counts and deltas:
> open
I think that the main advantage of "unstable" over "semi-stable" is
that it's a single word :-D It avoids the really hard question (!)
about the separator between "semi" and "stable" ;-) (semistable?
semi-stable? semi_stable?).
Victor
___
Python-Dev
> Rejected Ideas
> ==
>
> It might be good to add a similar tier in the Python (not C) API,
> e.g. for ``types.CodeType``.
> However, the opt-in mechanism would need to be different (if any).
> This is outside the scope of the PEP.
For types.CodeType constructor, would it be possible
Ok, let me start with the serious business: API name.
I'm not comfortable with "semi-stable". Python already has a "limited
API" and a "stable ABI". Just by its name, it's unclear what
"semi-stable" means.
Honestly, I would be more comfortable with the name: "unstable API".
It would be clear
Hi,
The C++ version was discussed in the 2nd link that I gave in my first message:
https://github.com/python/cpython/issues/91321
Gregory wrote "If we can conditionally test new things based on C++XX
version, accumulating modern issue regression tests seems useful.
Otherwise 11 at minimum."
Recently, a issue about C++20 compatibility was reported:
"The Python library will not compile with a C++2020 compiler because
the code uses the reserved “module” keyword"
https://github.com/python/cpython/issues/83536
In fact, after a long study, Python C API is *not* affected by this
issue.
Since we are you talking about tests, we can easily run the tests on
multiple C++ versions. But we have to start somewhere, so I propose to
start with C++11. More C++ versions can be tested later.
Victor
On Thu, Apr 28, 2022 at 5:54 AM wrote:
>
> > In terms of C++ version, it was proposed to
Hi,
If you got issues with using the Python C API in C++,
please speak up! I'm looking for feedback :-)
Extending Python by writing C++ code is now easy with the pybind11 project:
https://pybind11.readthedocs.io/
It seems like over the last years, building C++ extensions with the
Python C API
On Wed, Apr 27, 2022 at 5:56 PM Antoine Pitrou wrote:
> An environment variable is an easy to influence a program or system
> whose inner workings you don't control (for example a system that
> spawns child Python processes). And it sounds like a good idea to allow
> that given that it improves
cases are different enough to justify two
options, no?
Victor
On Tue, Apr 26, 2022 at 11:52 PM Victor Stinner wrote:
> The only purpose of proposed -P option is to "not add sys.path[0]".
> There are use cases which only need that.
>
> Victor
>
> On Tue, Apr 26, 2022 a
Since I didn't get any serious review on my pull request since
February, I created this thread on python-dev to get more people
looking into this issue.
On Wed, Apr 27, 2022 at 5:30 PM Paul Moore wrote:
>
> On Wed, 27 Apr 2022 at 15:32, Victor Stinner wrote:
> >
> > On Tue,
Oh sorry, I mean that I prefer to *not* add an environment variable,
but I'm not strongly against it.
How would the environment varaible be used? A command line option is not enough?
Victor
On Wed, Apr 27, 2022 at 4:44 PM Antoine Pitrou wrote:
>
> On Tue, 26 Apr 2022 11:46:41 +0200
&g
On Tue, Apr 26, 2022 at 11:46 AM Victor Stinner wrote:
> I propose adding a -P option to Python command line interface to "not
> add sys.path[0]":
> https://github.com/python/cpython/pull/31542
My plan is to merge this change at 2022-05-05, the day before the
Python 3.11 fea
On Tue, Apr 26, 2022 at 8:37 PM Steve Dower wrote:
> The biggest issue I see is that the obvious command line options for
> "import site" are already used to imply "do not import site". But then,
> -P isn't obvious either. Maybe an -X option would suffice?
I propose the short option "-P" rather
The only purpose of proposed -P option is to "not add sys.path[0]".
There are use cases which only need that.
Victor
On Tue, Apr 26, 2022 at 8:37 PM Steve Dower wrote:
>
> On 4/26/2022 10:46 AM, Victor Stinner wrote:
> > I propose adding a -P option to Python
Hi,
There are 4 main ways to run Python:
(1) python -m module [...]
(2) python script.py [...]
(3) python -c code [...]
(4) python [...]
(1) and (2) insert the directory of the module/script at sys.path[0].
(3) and (4) insert an empty string at sys.path[0].
This behavior is convenient and is
On Tue, Apr 26, 2022 at 5:47 AM Brett Cannon wrote:
> After talking about this in the SC today, we agreed to deprecate mailcap
> under the auspices of PEP 594:
> https://github.com/python/peps/commit/701999a91dc5f976c00d5bde1510226ebd9c7822
> .
Good. I proposed
On Fri, Apr 22, 2022 at 2:52 PM Fabio Zadrozny wrote:
> Humm, now I'm a bit worried... the approach the debugger is using gets the
> PyFrameObject that's about to be executed and changes the
> PyFrameObject.f_code just before the execution so that the new code is
> executed instead.
You can
On Wed, Apr 20, 2022 at 1:44 PM Antoine Pitrou wrote:
> > For consumers of the C API (C extensions, Cython, pybind11, etc.),
> > once most implementation details will be hidden, the C API will become
> > way more stable.
>
> The *API* is quite stable already if you don't use the private/internal
On Wed, Apr 20, 2022 at 10:03 AM Antoine Pitrou wrote:
> If the HPy design is the long term goal, why not just recommend that
> people use HPy? And keep the C API for expert users with specific
> needs that are not accomodated by HPy.
>
> To me, it seems that trying to change the C API to be
6 months ago, I wrote a different document based on HPy Manifesto:
"PEP: Taking the Python C API to the Next Level"
https://mail.python.org/archives/list/python-dev@python.org/message/RA7Q4JAUEITJBOUAXFEJKRRM2RR3QSZI/
Victor
On Mon, Apr 4, 2022 at 5:20 PM Petr Viktorin wrote:
>
> On 03. 02. 22
Hi,
In 2017, I proposed to document the feature, but nobody was volunteer
to write the doc (issue still open):
https://bugs.python.org/issue25571
I added a bare minimum mention of this feature in the "Python Debug
Build" documentation:
PEP 670 – Convert macros to functions in the Python C API:
https://peps.python.org/pep-0670/
That's great! Thanks to everyone who was involved in PEP 670: the
feedback helped Erlend and me to write a better PEP. It was a long
journey, Erlend started the first discussion about macros in March
While it's different than you proposal, some people may like this
magic "smart imports" project which lazily imports a module when it's
used :-)
Project: https://pypi.org/project/smart-imports/
Replace:
---
import math
from my_project import calc
# 100500 other imports
def my_code(argument,
On Thu, Apr 7, 2022 at 12:02 PM Petr Viktorin wrote:
> - This API stays with the regular public API (Include/cpython/), but to
> use it you'll need to #define Py_USING_UNSTABLE_API (name up for
> bikeshedding).
Since there is already something similar called "Py_LIMITED", I
suggest dropping
Hi,
Would it be possible to announce new PEPs on python-dev please?
I don't go often to Discourse, like once a month. I don't get any
notification by email. I expected new PEPs to be announced on
python-dev, but they are not announced here anymore. Is it possible to
get Discourse notifications
On Thu, Apr 7, 2022 at 5:35 AM Inada Naoki wrote:
> I just submitted the PEP 686 to the SC.
> https://github.com/python/steering-council/issues/118
>
> In this PEP, I am proposing:
>
> a. Small improvement for UTF-8 mode in Python 3.11
> b. Make UTF-8 mode default in Python 3.13.
It's easier to
IMO adding locale.getencoding() to Python 3.11 is not controversial
and is useful even if PEP 686 is rejected. This function was discussed
for 1 year (bpo-43510, bpo-43552, bpo-43557, bpo-47000) and there is
an agreement that there is a need for this function.
> Making `open(path,
Hi,
Steve, Petr: sorry if you feel that I didn't take your feedback in
account, it's not case. Thanks for your valuable feedback. It seems
like there was some misunderstanding.
On Tue, Apr 5, 2022 at 2:49 AM Gregory P. Smith wrote:
> Thanks for bringing this up on python-dev, Victor. That was
On Sun, Apr 3, 2022 at 3:29 PM Nick Coghlan wrote:
> The changes you've made have been excellent, and the existing 3 categories
> (stable public ABI, stable public API, unstable internal API) cover the vast
> majority of cases.
>
> The final case that isn't quite covered yet is to offer a
IMO it would be better to keep the HPy design as the long term goal:
* Refer to Python objects with opaque handles
* All structures are opaque (with a few exceptions, like PyType_Spec)
It will likely take multiple iterations (Python releases) to reach
this goal, and incompatible C API changes
PEP 603 adds a frozenmap type to collections, implemented as HAMT.
For a read-only *dict*, I proposed PEP 416 "Add a frozendict builtin
type" in 2012. It was rejected.
https://peps.python.org/pep-0416/
The outcome of this PEP was the addition of the types.MappingProxy
type (previously, it
Hi,
In 2019, Yury Selivanov, who added HAMT and contextvars to Python,
wrote PEP 603 "Adding a frozenmap type to collections":
https://peps.python.org/pep-0603/
Sadly, the PEP was stuck in discussions:
*
https://discuss.python.org/t/pep-603-adding-a-frozenmap-type-to-collections/2318
*
I created https://bugs.python.org/issue47185 to discuss this issue:
either recompute automatically co_exceptiontable, or at least document
the change.
Victor
On Fri, Apr 1, 2022 at 11:21 AM Victor Stinner wrote:
>
> ("Re: C API: Move PEP 523 "Adding a frame evaluation API to CP
("Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython"
private C API to the internal C API")
On Fri, Apr 1, 2022 at 11:01 AM Chris Angelico wrote:
>
> On Fri, 1 Apr 2022 at 19:51, Victor Stinner wrote:
> > In Python, sadly the types.CodeType ty
Hi,
Update on this issue: I merged my 2 PRs.
https://bugs.python.org/issue46850
The following APIs have been moved to the internal C API:
- _PyFrameEvalFunction type
- _PyInterpreterState_GetEvalFrameFunc()
- _PyInterpreterState_SetEvalFrameFunc()
- _PyEval_EvalFrameDefault()
If you use any of
On Wed, Mar 30, 2022 at 5:42 PM Guido van Rossum wrote:
> In the not so distant past I have proposed to introduce a new category,
> "Unstable APIs". These are public but are not guaranteed to be backwards
> compatible in feature releases (though I feel they should remain so in bugfix
>
On Mon, Mar 28, 2022 at 1:44 PM Petr Viktorin wrote:
> Perhaps we need a new "tier" of C API for debuggers -- API that's
> guaranteed stable for a major release, and if it's changed it should
> always break with compile errors (e.g. the function gets a new
> argument), rather than silently change
On Wed, Mar 30, 2022 at 9:26 PM Sebastian Berg
wrote:
> That is fair, although there are documented underscored ones:
> https://docs.python.org/3/search.html?q=_Py
>
> I suppose that means all bets are off _unless_ it is documented or
> later adopted as stable API (e.g.
The internal C API can be used on purpose. But there is no backward
compatibility warranty and it can change anytime. In practice, usually
it only changes in 3.x.0 releases. For example, these private C API
changed in Python 3.9 and Python 3.11 (see my first email in the other
PEP 523 thread).
To
On Wed, Mar 30, 2022 at 2:26 AM Steve Dower wrote:
> Right now, the API is allowed/expected to change between 3.x releases
> (which normally we don't allow without a deprecation period) but it
> still has to remain compatible within a single 3.x release. Making it
> fully internal *without adding
On Tue, Mar 22, 2022 at 7:33 PM Steve Dower wrote:
> After a normal deprecation period, yes?
There is no backward compatibility warranty and no deprecation process
for private APIs.
Victor
___
Python-Dev mailing list -- python-dev@python.org
To
Hi,
I proposed two PRs to move the private C API (Include/cpython/) of PEP
523 "Adding a frame evaluation API to CPython" to the internal C API
(Include/internals/):
* https://github.com/python/cpython/pull/32052
* https://github.com/python/cpython/pull/32054
API:
* _PyFrameEvalFunction type
*
Hi,
Oh, the Steering Council accepted PEP 594 "Removing dead batteries
from the standard library"! I just saw the announcement on Discourse.
Congratulations Christian and Brett! This PEP, first proposed in 2019,
wasn't an easy one.
https://peps.python.org/pep-0594/
Gregory P. Smith's message on
It would be great to have the list of supported platforms per Python version!
Maybe supporting new platforms and dropping support for a platform
should be document in What's New in Python x.y. GCC does that for
example. It also *deprecates* support for some platforms. Example:
On Fri, Mar 4, 2022 at 1:37 PM Eryk Sun wrote:
> I don't understand. The site packages directories, including virtual
> environments, are a site extension.
I propose to change that. Move all code related to sys.path from the
site module to the Modules/getpath.py module.
Victor
--
Night
Unrelated to the doc, now that getpath has been rewritten in pure
Python, thanks to Steve Dower!, it would be nice to move the last bits
of the sys.path initialization from the site module to the getpath
module. It's unpleasant to have a different sys.path depending if the
site module is loaded or
By the way, AMD64 Arch Linux Usan 3.x started failing because I
enabled more tests on this buildbot yesterday.
Previously, "test_faulthandler test_hashlib test_concurrent_futures
test_ctypes" were simply skipped on this UBSAN buildbot.
I'm working on fixing the 3 failing tests: test_ctypes,
Hi,
I tried to document inputs and outputs of Modules/getpath.py in the C
API Initialization API:
https://docs.python.org/dev/c-api/init_config.html#python-path-configuration
I don't know if it would be possible to merge most of these
information at a single place to avoid oudated documentation.
The consensus is to require IEEE 754 to build CPython, but not require
it in the Python language specification.
Updates (changed merged in bpo-46656):
* Building Python 3.11 now requires a C11 compiler without optional
C11 features. I wrote it in What's New in Python 3.11 and the PEP 7.
*
On Thu, Feb 24, 2022 at 11:10 PM Barry wrote:
> > "Python 3.11 and newer versions use C11 without optional features. The
> > public C API should be compatible with C++."
> > https://github.com/python/peps/pull/2309/files
>
> Should is often read as meaning optional when writing specs.
> Can you
Ok, let me try something simpler:
"Python 3.11 and newer versions use C11 without optional features. The
public C API should be compatible with C++."
https://github.com/python/peps/pull/2309/files
Victor
___
Python-Dev mailing list --
On Wed, Feb 23, 2022 at 7:11 PM Petr Viktorin wrote:
> I did realize there's one more issue when converting macros or static
> inline functions to regular functions.
> Regular functions' bodies aren't guarded by limited API #ifdefs, so if
> they are part of the limited API it's easy to forget to
On Wed, Feb 23, 2022 at 7:11 PM Petr Viktorin wrote:
> In the PEP, the "Performance and inlining" section seems unnecessary. It
> talks about attributes that aren't used in the implementation. Or are
> they? How does the section relate to the rest of the PEP?
> The "Benchmark comparing macros and
Hi,
I updated my PEP 7 PR to use C99 in the public C API and "a subset of"
C11 in Python internals:
"Python 3.11 and newer versions use C99 in the public C API and use a
subset of C11 in Python internals. The public C API should be
compatible with C++. The C11 subset are features supported by
On Tue, Feb 22, 2022 at 1:54 PM Petr Viktorin wrote:
> First, add notices to any documentation that using the macro as a
> l-value is a deprecated, CPython-specific detail. It should be clear
> that the only reason this usage is allowed is for backwards
> compatibility, and that alternate
Hi,
Thanks for looking into my PEP 674!
I don't understand well why Py_SIZE() cannot be changed until
Py_SET_SIZE() is available on all supported Python versions (so
affected projects don't have to add a compatibility code), whereas
it's ok to require a compatibility code to keep support for
Hi,
Since Erlend and me posted PEP 670 on python-dev last October, we took
all feedback (python-dev and Steering Council) in account to clarify
the intent of the PEP and to reduce its scope (remove *any* risk of
backward compatibility).
PEP 670: https://python.github.io/peps/pep-0670/
Changes
;-)
Victor
On Mon, Feb 14, 2022 at 11:29 AM Antoine Pitrou wrote:
>
> On Wed, 9 Feb 2022 17:49:19 +0100
> Victor Stinner wrote:
> > On Wed, Feb 9, 2022 at 1:04 PM Petr Viktorin wrote:
> > > > Right now, a large number of macros cast their argument to a t
Results of the poll (which was open for 10 days):
* Move pythoncapi_compat: 19 votes (90%)
* Don't move pythoncapi_compat: 2 votes (10%)
Victor
On Fri, Feb 11, 2022 at 12:16 AM Victor Stinner wrote:
>
> I created a poll on Discourse:
> https://discuss.python.org/t/move-the-pythonca
On Fri, Feb 11, 2022 at 3:14 PM Petr Viktorin wrote:
> Sounds reasonable, but...
>
> The implication of endorsing code like this is that *we cannot change
> private API even in patch releases*, which I don't think is documented
> anywhere, and might be a bit controversial.
> (I'm still planning
IMO we need to distinguish the public C API which should be as much
compatible as possible, target the oldest C standard, and the Python
internals can require a more recent C standard.
For example, today maybe it's reasonable to requires C99 for Include/
headers (public .h files) and support C11
On Fri, Feb 11, 2022 at 12:06 PM Petr Viktorin wrote:
> Or will this send a message that core devs should co-maintain the project?
> I personally wouldn't want to maintain it, but it it looks like there
> are at least 3 maintainers who do.
I think that Neal provided a better answer than me :-)
I created a poll on Discourse:
https://discuss.python.org/t/move-the-pythoncapi-compat-project-under-the-github-python-or-psf-organization/13651
It will be closed automatically in 10 days.
Victor
___
Python-Dev mailing list -- python-dev@python.org
To
Hi,
Would it make sense to move the pythoncapi_compat project under the
GitHub Python or PSF organization to make it more "official" and a
little bit more sustainable?
"The pythoncapi_compat project can be used to write a C extension
supporting a wide range of Python versions with a single code
On Thu, Feb 10, 2022 at 10:28 AM Petr Viktorin wrote:
> Ah, I've also wanted anonymous unions in the past!
> There's a little problem in that they're not valid in C++, so we can't
> have them in public headers.
>
> We'll need to mention C++ if we update the standard.
IMO we only have to care
On Thu, Feb 10, 2022 at 10:58 AM Petr Viktorin wrote:
>
> On 09. 02. 22 21:41, Gregory P. Smith wrote:
> >
> > On Wed, Feb 9, 2022 at 8:54 AM Victor Stinner > Perhaps use a hybrid approach
> > when feasible similar to:
> >#define PyUnicode_CHECK_INTERNED(
On Wed, Feb 9, 2022 at 5:48 PM Pablo Galindo Salgado
wrote:
> We consider the representation of co_postions private, so we don't want (for
> now) to ad
> getters/setters. If you want to get the position of a instruction, you can
> use PyCode_Addr2Location
The code.co_positions() method is
Hi,
It's already possible to call PyObject_CallMethod(code,
"co_positions", NULL) and then use the iterator in C. Is there an use
case where performance of reading co_positions is critical? If not,
there is no need to add a specialized function.
Victor
On Wed, Feb 9, 2022 at 5:23 PM Petr
On Wed, Feb 9, 2022 at 1:04 PM Petr Viktorin wrote:
> > Right now, a large number of macros cast their argument to a type. A
> > few examples:
> >
> > #define PyObject_TypeCheck(ob, type)
> > PyObject_TypeCheck(_PyObject_CAST(ob), type)
> > #define PyTuple_GET_ITEM(op, i)
Hi Petr,
Thanks for the SC review, it's very helpful! I know that it's a big PEP :-)
On Tue, Feb 8, 2022 at 11:33 AM Petr Viktorin wrote:
> *All other things being equal, static inline functions are better than
> macros.*
> Specifically, inline static functions should be preferred over
>
On Tue, Feb 8, 2022 at 2:02 PM Steve Dower wrote:
> All the C99 library is supposedly supported, but there are (big?) gaps
> in the compiler support.
Some Visual Studio 2019 updates on the Microsoft blog.
March 2020: C99 _Pragma
1 - 100 of 3149 matches
Mail list logo
