[Python-Dev] Re: Can I ask a real dumb procedural question about GitHub email?

2022-05-05 Thread Victor Stinner
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
___
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/2E5D7WGNZL2BGQEQEURSJ4HN7WWTADLT/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

2022-05-05 Thread Petr Viktorin
On Thu, May 5, 2022 at 5:35 AM Thomas Wouters  wrote:
[...]
>
>
> I've already brought this up to Petr directly, but I would greatly prefer new 
> unstable API functions have leading underscores, and that existing functions 
> being moved to the unstable API are _not_ renamed.
>
> Renaming existing functions means a lot of unnecessary code churn. It looks 
> like we have more _-prefixed unstable functions than not, but I don't think 
> the churn is worth renaming the currently public ones.
>
> Leading underscores for unstable API functions (that aren't currently public) 
> means we keep the widely assumed guarantee that Py*/PY* are part of the 
> public API. The Py_USING_UNSTABLE_API define is per-file, not per symbol/use, 
> so I would rather not open the door to unintended or unaware use of unstable 
> APIs. By giving the functions the leading underscore, we're forcing people to 
> think about -- or check the documentation -- whether the specific function is 
> okay to use.
>
> The unstable API is intended for specific use-cases, and I think it's 
> preferable to put the burden of figuring out if a _Py/_PY* symbol is 
> acceptable for them to use, rather than putting the burden of figuring out if 
> a Py/PY* symbol is acceptable up use on _everyone else_.
>

I don't think that's necessary. I still see the unstable API as
public: it needs more maintenance, but it's not particularly dangerous
to use it.
I think defining Py_USING_UNSTABLE_API once is quite enough.
___
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/RHQYGRQL6HWT6PC52BRKKVI6CUPHFT36/
Code of Conduct: http://python.org/psf/codeofconduct/


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

2022-05-05 Thread Victor Stinner
Ah, I see that I didn't explain something well.

The issue has two sides: one side is a fix security vulnerability, the
second side is more about Python *usability*.

The Python usability issue is that running "math.py" overrides the
Python stdlib module called "math". "math.py" is just an example,
Python 3.11 contains has 305 modules: a name conflict is likely,
especially by users learning Python fall into this trap (create a file
called "random.py" to play with the "random" module).

The issue so common that IPython added a "launcher" to work around
this issue, to remove sys.path[0]:
https://github.com/ipython/ipykernel/commit/3f7a03d356eee3500261acf9eec6bad2196c2097

Another example is the pytest project: running "pytest [...]" is
different than "python -m pytest [...]". The second command adds the
current working directory which can change the test behavior. It's a
documented issue:
https://docs.pytest.org/en/latest/how-to/usage.html#calling-pytest-through-python-m-pytest

For the pytest use case, you still want to add the user site directory
to sys.path and you still want to accept PYTHON environment variables
like PYTHONWARNINGS. The only thing that you don't want is to add the
current working directory to sys.path.

Read also this discussion by Miro Hrončok about this usability issue in Fedora:
https://discuss.python.org/t/python-flag-envvar-to-not-put-current-directory-on-sys-path-but-dont-ignore-pythonpath/4235

Victor

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



-- 
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/A65CZFDNPXGBMENQD56VHF2QXDS3ENIC/
Code of Conduct: http://python.org/psf/codeofconduct/