[Python-Dev] PEP 689 – Semi-stable C API tier

[Petr Viktorin]

Hello,
Victor and others are organizing the C-API to make it clearer what's 
public and what's private (see Victor's file-based stats: 
https://pythoncapi.readthedocs.io/stats.html)


It became clear that we need a tier between public and private C-API. 
PEP 689 proposes such API, with an opt-in macro and transition period.


Please discuss.
And if you can think of a better name, that would be great :)



The PEP is at: https://peps.python.org/pep-0689/
Thread where this started: 
https://mail.python.org/archives/list/python-dev@python.org/thread/MA4FQ7G6F35NG3TUN6RQPXRGXTYMFMDY/#MA4FQ7G6F35NG3TUN6RQPXRGXTYMFMDY

Implementation notes: https://github.com/python/cpython/issues/91744

Here's the current version for easy quoting:

--

PEP: 689
Title: Semi-stable C API tier
Author: Petr Viktorin 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Requires: 523
Created: 22-Apr-2022
Python-Version: 3.11


Abstract


Some functions and types of the C-API are designated *semi-stable*,
meaning that they will not change in patch (bugfix/security) releases,
but may change between minor releases (e.g. between 3.11 and 3.12) without
deprecation warnings.


Motivation & Rationale
==

The Python C-API is currently divided into `three tiers 
`__:


- Limited API, with high compatibility expectations
- Public API, which follows the :pep:`backwards compatibility policy
  <387>`, and requires deprecation warnings before changes
- Private (internal) API, which can change at any time.

We need a tier between Public and Private to accommodate tools like
advanced debuggers and JIT compilers, which need access to CPython
internals but assume the C-API they use does not change in patch releases.


Setting Stability Expectations
--

Currently, there are no guarantees for the internal API -- that is, anything
that requires ``Py_BUILD_CORE`` or is named with a leading underscore.
This API can change without warning at any time, and code that uses it
is pinned to a specific build of Python.

However, in practice, even the internal API usually happens to be stable
in patch releases:

- Some CPython core developers take this as an an unwritten rule.
- Patch releases only contain bugfixes, which are unlikely to
  change the API.

Semi-stable API will make the stability expectations more explicit.

It will also hopefully encourage existing users of the private API to
reach out to python-dev, so we can expose, standardize and test an API
for some of their use cases.


Reserving underscores for Private API
-

:pep:`523` introduced functions for use by debuggers and JIT compilers,
which are stable only across minor releases.
The functions names have leading underscores to suggest their limited
stability.

However, leading underscores usually mark *fully private* API.
CPython developers familiar with the “underscore means internal”
convention are unlikely to check if underscored functions they are
changing are documented and used outside CPython itself.

This proposal brings us a bit closer to reserving underscores
only for truly private, unstable, hands-off API.


Warning about API that is changed often
---

The ``PyCode_New()`` family is an example of functions that are
documented as unstable, and also often change in practice.

Moving it to the semi-stable tier will make its status obvious even
to people who don't read the docs carefully enough, and will make it
hard to use accidentally.


Changes during the Beta period
--

Since the API itself can change continuously up until Beta 1 (feature 
freeze)

of a minor version, major users of this API are unlikely to test
Alpha releases and provide feedback.
It is very difficult to determine what needs to be exposed as semi-stable.

Additions to the semi-stable tier will count as *stabilization*,
and will be allowed up to Release Candidate 1.


Specification
=

Several functions and types (“APIs”) will be moved to a new 
*semi-stable* tier.


They will be expected to stay stable across patch releases,
but may change or be removed without warning in minor releases (3.x.0),
including Alpha and Beta releases of 3.x.0.

When they change significantly, code that uses them should no longer compile
(e.g. arguments should be added/removed, or a function should be renamed,
but the semantic meaning of an argument should not change).

Their definitions will be moved to a new directory, ``Include/semistable/``,
and will be included from ``Python.h``.

From Python 3.12 on, these APIs will only be usable when the
``Py_USING_SEMI_STABLE_API`` macro is defined.
CPython will only define the macro for building CPython itself
(``Py_BUILD_CORE``).

To make transition to semi-stable API easier,
in Python 3.11 the APIs will be available without 
``Py_USING_SEMI_STABLE_API``

defined. In this case, u

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Victor Stinner]

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 than a long option like -X
dont_add_path0 to be able to use the option in a Unix shebang. Sadly,
Unix shebangs don't support long options (it's only possible to use a
single long option per shebang, it's not convenient).

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UPXCCOO3LGZLVLABHO4SK3T2QCUPH4ZZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Victor Stinner]

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 feature freeze, unless someone has a good reason to not
add this option or if you consider that we need more time to think
about this issue.

This issue is being discussed for 11 years, see for example:

* https://bugs.python.org/issue13475
* 
https://discuss.python.org/t/python-flag-envvar-to-not-put-current-directory-on-sys-path-but-dont-ignore-pythonpath/4235

Victor
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SXREVOEEIQL7M5YLTMFIOLLLHXRCI362/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Antoine Pitrou]

On Tue, 26 Apr 2022 11:46:41 +0200
Victor Stinner  wrote:
> I prefer to add an environment variable, only pass the option
> explicitly on the command line.

I don't really understand this sentence, can you rephrase?



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/L4KBLOSENGMPVQARKWAUXUQKTIP2OFPL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Paul Moore]

On Wed, 27 Apr 2022 at 15:32, Victor Stinner  wrote:
>
> 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 feature freeze,

Why leave it until the last minute? That just makes it harder to
revert if someone immediately finds a problem with it.

> unless someone has a good reason to not
> add this option or if you consider that we need more time to think
> about this issue.
>
> This issue is being discussed for 11 years, see for example:

It seems very rushed to propose this and implement it days before 3.11
freeze. If it's been an issue for 11 years, then (a) why didn't anyone
propose this solution months ago, and (b) surely it can wait another
year?

I don't have any particular objection to the feature, but whether you
mean it to or not, the short timescale gives the impression that
you're trying to rush something in without giving people time to
discuss or consider alternatives. People have other things to do, and
can't simply produce a response in a matter of hours. Apart from
anything else, aren't a lot of people who might be interested going to
be occupied with PyCon right now? Steve Dower mentioned some (IMO)
reasonable points, and you pretty much dismissed them without any
discussion. That doesn't seem like the right way to handle this. In
particular, I think the question of how this flag interacts with all
the other flags and settings that affect sys.path and how "isolated"
Python is, is an important thing to consider[^1].

Paul

[^1]: We've had multiple attempts to get locale and UTF8 handling
right, and now have a mess of flags, environment variables, and
options that frankly only the experts can understand. I fear that we
could end up with the same issue for "Python initialisation flags" if
we don't take a less rushed approach.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JBQTRPWB5PJV4S3S2SFESYOQQ2B2E5CY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Victor Stinner]

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
> Victor Stinner  wrote:
> > I prefer to add an environment variable, only pass the option
> > explicitly on the command line.
>
> I don't really understand this sentence, can you rephrase?
>
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/L4KBLOSENGMPVQARKWAUXUQKTIP2OFPL/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HOJM3LHUQZBCRK6RZBHIG6H3WGLKRDFT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Antoine Pitrou]

On Wed, 27 Apr 2022 17:37:20 +0200
Victor Stinner  wrote:
> 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?

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 security?

Regards

Antoine.


> 
> Victor
> 
> On Wed, Apr 27, 2022 at 4:44 PM Antoine Pitrou  wrote:
> >
> > On Tue, 26 Apr 2022 11:46:41 +0200
> > Victor Stinner  wrote:  
> > > I prefer to add an environment variable, only pass the option
> > > explicitly on the command line.  
> >
> > I don't really understand this sentence, can you rephrase?
> >
> >
> >
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-le...@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at 
> > https://mail.python.org/archives/list/python-dev@python.org/message/L4KBLOSENGMPVQARKWAUXUQKTIP2OFPL/
> > Code of Conduct: http://python.org/psf/codeofconduct/  
> 
> 
> 



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NWEXTHGRN4VJ5W54XEW5LJUBUXMXFMXJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Victor Stinner]

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, 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 feature freeze,
>
> Why leave it until the last minute? That just makes it harder to
> revert if someone immediately finds a problem with it.

I wrote my PR in February. If it goes wrong, we will have until
October to revert it. The idea is to merge it before beta1 to have 6
months to play with it and check for corner cases.


> It seems very rushed to propose this and implement it days before 3.11
> freeze. If it's been an issue for 11 years, then (a) why didn't anyone
> propose this solution months ago, and (b) surely it can wait another
> year?

Different solutions were proposed over the last 11 years. See for
example: https://bugs.python.org/issue13475

Sadly, no solution was merged into Python, only discussed.


> Steve Dower mentioned some (IMO)
> reasonable points, and you pretty much dismissed them without any
> discussion. That doesn't seem like the right way to handle this. In
> particular, I think the question of how this flag interacts with all
> the other flags and settings that affect sys.path and how "isolated"
> Python is, is an important thing to consider[^1].

See the init_config.rst documentation of my PR: isolated=1 implies
add_path=0 (no behavior change)
https://github.com/python/cpython/pull/31542/files

Running Python with a ._pth file implies isolated=1 and so add_path=0
(no behavior change).

It seems like Steve's proposal is orthogonal, but I don't think that
it's exclusive. We can add a second option, no?


> [^1]: We've had multiple attempts to get locale and UTF8 handling
> right, and now have a mess of flags, environment variables, and
> options that frankly only the experts can understand. I fear that we
> could end up with the same issue for "Python initialisation flags" if
> we don't take a less rushed approach.

The locale encoding, the Python filesystem encoding and the Python
UTF-8 Mode are way more complicated problems. I spent years to fix
issues about these, so I'm well aware of these issue. By the way, I
also designed PEP 587 PyConfig API and I implemented it.

Here the -P option effect is restricted to a single function:
pymain_run_python(). My pull request can be summarized as:

- else if (!config->isolated) {
+ else if (config->add_path0) {

Do you think that we should pay attention to something in specific?
Right now, I propose to not add an environment variable and -P is
unrelated to -E (ignore env vars).

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BFZIGOIVCBNSHBQS7JHKXWWYTENGUWJO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Victor Stinner]

The use case for -P still uses environment variables like
PYTHONWARNINGS or PYTHONUTF8. That's why -I (isolated) cannot be used.

If there is an use case for a ._pth file importing 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 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 command line interface to "not
> > > add sys.path[0]":
> > > https://github.com/python/cpython/pull/31542
> > >
> > > See the documentation in the PR for the exact behavior of this option.
> > > I prefer to add an environment variable, only pass the option
> > > explicitly on the command line.
> >
> > Another viable option might be to add an option to imply "import site",
> > which would work together with -I to:
> > * ignore environment variables (-E/-I)
> > * omit implicit CWD imports (-I)
> > * still process .pth files (-?)
> > * still include site-packages and user site-packages in sys.path (-?)
> >
> > It seems likely that the proposed -P would almost always be used with
> > -E, since if you can't control CWD then you presumably can't control
> > environment variables either.
> >
> > The existing ._pth functionality starts by implying -I, and allows
> > "import site" in the file to explicitly include site. A command-line
> > option matching this behaviour would be consistent. There's also already
> > configuration in our structures for import site, so there'd be no need
> > to add new fields to public APIs for the option.
> >
> > 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?
> >
> > Cheers,
> > Steve
> >
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RHRRPR2QM6VKN36YGKWNGHE4UQWJXEZC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Victor Stinner]

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 security?

Ok, you changed my mind and I added PYTHONDONTADDPATH0=1 env var. Example:

$ ./python -c 'import sys, pprint; pprint.pprint(sys.path)'
['',
 '/usr/local/lib/python311.zip',
 '/home/vstinner/python/main/Lib',
 '/home/vstinner/python/main/build/lib.linux-x86_64-3.11-pydebug',
 '/home/vstinner/.local/lib/python3.11/site-packages']

$ PYTHONDONTADDPATH0=1 ./python -c 'import sys, pprint; pprint.pprint(sys.path)'
['/usr/local/lib/python311.zip',
 '/home/vstinner/python/main/Lib',
 '/home/vstinner/python/main/build/lib.linux-x86_64-3.11-pydebug',
 '/home/vstinner/.local/lib/python3.11/site-packages']

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JQHOHQ5VSY3AZBQQXO655YE2YB4AJQV2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Using the Python C API in C++

[Victor Stinner]

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 started to emit more C++ compiler warnings. One
explanation may be that converting macros to static inline functions
(PEP 670) introduce new warnings, even if the old and the new code is
exactly the same. I just discover this issue recently. C and C++
compilers treat static inline functions differently. Macros are
treated at legacy code which cannot be fixed, like system headers or
old C header files, and so many warnings are made quiet. Static inline
functions (defined in header files) are treated as regular code and
compilers are more eager to emit warnings.

I just modified the Python C API to use C++ static_cast(expr)
and reinterpret_cast(expr) if it's used with C++. In C, the
regular (type)expr cast (called "old-style cast" by C++ compilers ;-))
is still used as before.

I'm also working on adding an unit test to make suite that using the
Python C API works with a C++ compiler and doesn't emit compiler
warnings:

* https://github.com/python/cpython/issues/91321
* https://github.com/python/cpython/pull/32175

In terms of C++ version, it was proposed to target C++11.

In the pythoncapi-compat project, I got warnings when the NULL
constant is used in static inline functions. I modified the
pythoncapi_compat.h header file to use nullptr if used with C++ to fix
these compiler warnings. So far, I'm unable to reproduce the issue
with , and so I didn't try to address this issue in Python.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/73UTO4MTKVJR7XWXTHLOV3V2L2QKP2TK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Paul Moore]

On Wed, 27 Apr 2022 at 16:50, Victor Stinner  wrote:
>
> 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.

Pull requests don't get much visibility from the wider community - I
know I can't keep up with all the PRs submitted. Creating a thread on
python-dev seems reasonable. Doing so with about a week until feature
freeze seems less so. I'm not going to comment further on this
specific proposal, except maybe to respond to other people's comments.
I don't have enough time in the coming week to think through the
implications and possibilities myself.

Paul
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HDHESOPY3LZPZGN5II67GZPNPMYZ4E7X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Barry]

> On 27 Apr 2022, at 17:22, Victor Stinner  wrote:
> 
> Ok, you changed my mind and I added PYTHONDONTADDPATH0=1 env var. Example:

Maybe the env var say what it is not adding rather then where it adds it.
PYTHONDONTADDPWD=1

Barry
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RT5M26HLDMN4QD7XOYEUO5HTUYIF55ZA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Miro Hrončok]

On 27. 04. 22 20:45, Barry wrote:




On 27 Apr 2022, at 17:22, Victor Stinner  wrote:

Ok, you changed my mind and I added PYTHONDONTADDPATH0=1 env var. Example:


Maybe the env var say what it is not adding rather then where it adds it.
PYTHONDONTADDPWD=1


But it is not "just" the PWD. In the case of shebangs, it's actually the 
script's directory. E.g. a script in /usr/bin/ normally has /usr/bin/ in 
sys.path (which is not desired, hence we (Fedora) would probably add the -P 
flag to default shebangs for programs in /usr/bin/).


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EZSJKN3WH7IP3EDJ5RFUV52RYBZX37GO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Miro Hrončok]

On 27. 04. 22 21:34, Steve Holden wrote:

So would PYTHONDONTADDSCRIPTDIR=1 be a better choice?


No because for other invocations, it prevents PWD being added, not the 
scriptdir. Both names are bad becasue they only describe half of what's it 
doing (or maybe the option should not do both, if it's hard to explain).


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CJ5G2HEHISXFSLSXPC4F6TNVUBE2TKIX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

[Barry Scott]

> On 27 Apr 2022, at 20:21, Miro Hrončok  wrote:
> 
> On 27. 04. 22 20:45, Barry wrote:
>>> On 27 Apr 2022, at 17:22, Victor Stinner  wrote:
>>> 
>>> Ok, you changed my mind and I added PYTHONDONTADDPATH0=1 env var. Example:
>> Maybe the env var say what it is not adding rather then where it adds it.
>> PYTHONDONTADDPWD=1
> 
> But it is not "just" the PWD. In the case of shebangs, it's actually the 
> script's directory. E.g. a script in /usr/bin/ normally has /usr/bin/ in 
> sys.path (which is not desired, hence we (Fedora) would probably add the -P 
> flag to default shebangs for programs in /usr/bin/).

naming is so hard... may do "don't add implicit dirs"?

PYTHONDONTADDIMPLICTDIRS=1

(I wish there where _ to show the word boundaries, but that ship has sailed)

Barry

> 
> -- 
> Miro Hrončok
> -- 
> Phone: +420777974800
> IRC: mhroncok
> 

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AOKTSCZJXXV4Q6CZPURBHXKIIPWEANGX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Using the Python C API in C++

[h . vetinari]

> In terms of C++ version, it was proposed to target C++11.

GCC 5 has full C++14 support (one library functionality missing), and so does 
VS2015 onwards as well as Clang 3.4, see
https://en.cppreference.com/w/cpp/compiler_support

I doubt that any older compilers are in use _anywhere_ in reasonable numbers 
that this should constrain the development of CPython.

While I don't know who proposed C++11 or where, I'd therefore like to propose 
to move to _at least_ C++14.

Note that https://github.com/python/peps/pull/2309 already bumped the required 
C-standard to C11, and originally defined this as
> The C11 subset are features supported by GCC 8.5,
> clang 8.0, and MSVC of Visual Studio 2017.

If those versions should be regarded as the lower bounds of compiler support 
(are they - or anything lower - tested on the build bots...?), then C++17 core 
language support would automatically fall out of this (there are some 
stragglers for full stdlib support, especially in clang; but that is usually 
not an issue).

Best
H.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AGUI6B6W55TUXL6SA7KQQGPYYSRJNCFH/
Code of Conduct: http://python.org/psf/codeofconduct/