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

[Thomas Wouters]

On Wed, May 4, 2022, 04:11 Petr Viktorin  wrote:

>
>
> On 29. 04. 22 19:02, Guido van Rossum wrote:
> > On Fri, Apr 29, 2022 at 10:15 AM Petr Viktorin  > > wrote:
> >
> > On 29. 04. 22 16:32, Victor Stinner wrote:
> >  > 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.
> [...]
> > Nick Coghlan argued against that term:
> [...]
> > But I also like “unstable” better than “semi-stable”. Splitting the
> > internals into “private”/“internal” and “unstable” seems reasonable.
> >
> >
> > I think picking "semi-stable" would be giving in to the OCD nerd in all
> > of us. :-) While perhaps technically less precise, "unstable" is the
> > catchy name with the right association. (And yes, we should keep it
> > stable within bugfix releases, but the name doesn't need to reflect that
> > detail.) The "internal API" isn't an API at all (except for CPython core
> > developers and contributors). The "unstable API" would definitely be an
> > *API* for users outside the core.
> >
> > So let's please go with "unstable".
>
>
> Thanks, you worded that perfectly!
>
> Alright, the PEP now uses “unstable” rather than “semi-stable”. And I
> don't see any issues with the technical details, so I'll see if it can
> still get into Python 3.11. Hopefully Pablo agrees as the Release Manager.
> Thanks for the discussion, everyone!
>

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_.


___
> 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/L6IGXJ5OM2GHAFTAEWWB35STT3MBQL2J/
> 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/2CVRI26HEF6FMFUGCJNYLE5K6SHOHOWM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Erlend Egeberg Aasland]

On Wed, 4 May 2022 at 12:30, Skip Montanaro 
wrote:

> How (if at all) do people deal with this firehose of email?


I’ve disabled _all_ email notifications both on GitHub and Discourse. I
actively visit the GitHub Notification page when I want to see what’s on on
GitHub. Ditto for Discourse. This makes my life a lot easier, and I receive
fewer pings. (Those two are actually the same; it’s just different
wordings.) I don’t need more pings; I need a convenient UI that shows me
what I want, when I want it.

Another really nice thing with this is that the notifications are
_grouped_, both in the GitHub UI and the Discourse UI. I see one blue dot
for each PR or each thread. I know you get threads in email clients as
well, but I prefer the web UIs.

My 2 cents (or 2 øre if you’re in my home town)

Erlend

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

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

[Tim Peters]

[Skip Montanaro ]
> I subscribe to the python/cpython stuff on GitHub. I find it basically
> impossible to follow because of the volume.
> ...
> How (if at all) do people deal with this firehose of email? Am I the
> only person dumb enough to have tried?

My observation is that, over time, all sources of email strive to
enlist the aid of every electron in the universe to transform all of
creation into more copies of its output, directed to my gmail account.

I gave up. These days, if Google doesn't put something in the
"priority" section of my gmail inbox, chances are the only thing I'll
see of it is a fraction-of-a-second glance at the subject line as I
check the "select all" box, on page after page, before deleting it.
That gets done every day almost as often as clicking on "report spam
and unsubscribe".

I fondly remember the days when email volume was merely unbearable ;-)
___
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/FE7522WPE6Q3W55KNNFLVZXR6G3CWCNH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

On Wed, May 4, 2022 at 11:26 AM Skip Montanaro 
wrote:

> I subscribe to the python/cpython stuff on GitHub. I find it basically
> impossible to follow because of the volume. I realize there are
> probably plenty of extra changes going in based on the recent language
> summit (and maybe some sprints at PyCon?) as well as the proximity to
> the beta 1 freeze. Still, does anyone actually try to follow
> everything that comes out of that firehose? I've received updates to
> about 125 new GMail conversations (more total messages than that) in
> the last 24 hours, and that's after using filters to delete
> Miss-Islington-type messages altogether. As far as I can quickly
> ascertain, all the messages are from real people, not bots.
>
> How (if at all) do people deal with this firehose of email? Am I the
> only person dumb enough to have tried?


If no one replies, then you might be the only brave soul trying.  I
stopped years ago even under bpo.

-Brett


> I used to scan for
> csv-module-related messages, but don't even try to do that now. My
> only real reason for continuing to subscribe is that it feeds into a
> process that updates a dictionary of "common" words used by my
> XKCD-936-derived password generator.
>
> Thx,
>
> Skip
> ___
> 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/BCBQWW2ZLRU2GCSZJH6Q6YNAXMH3Q6FB/
> 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/BKPPZC6WE6LP5AHEZZVVUFESYOYAM6WZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Skip Montanaro]

I subscribe to the python/cpython stuff on GitHub. I find it basically
impossible to follow because of the volume. I realize there are
probably plenty of extra changes going in based on the recent language
summit (and maybe some sprints at PyCon?) as well as the proximity to
the beta 1 freeze. Still, does anyone actually try to follow
everything that comes out of that firehose? I've received updates to
about 125 new GMail conversations (more total messages than that) in
the last 24 hours, and that's after using filters to delete
Miss-Islington-type messages altogether. As far as I can quickly
ascertain, all the messages are from real people, not bots.

How (if at all) do people deal with this firehose of email? Am I the
only person dumb enough to have tried? I used to scan for
csv-module-related messages, but don't even try to do that now. My
only real reason for continuing to subscribe is that it feeds into a
process that updates a dictionary of "common" words used by my
XKCD-936-derived password generator.

Thx,

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

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

[Victor Stinner]

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 renamed "add_path0" to "safe_path" (opposite meaning) and I renamed
"PYTHONDONTADDPATH0" env var to "PYTHONSAFEPATH": shorter, easy to
write.

In terms of usability, IMO "safe_path=1" is easier to understand than
"add_path0=0". For the exact meaning of this option, well, I wrote
documentation.

In the documentation, I replaced "don't add sys.path[0]" with "don't
prepend an unsafe path to sys.path: (...)" with an explanation of
which "unsafe path" is prepended.

Adding this -P command line option makes the Python command line even
more complicated, with existing -I and -E options, the "._pth" file,
etc. But well, not all users want the same thing ;-)

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

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

[Petr Viktorin]

On 29. 04. 22 19:02, Guido van Rossum wrote:
On Fri, Apr 29, 2022 at 10:15 AM Petr Viktorin > wrote:


On 29. 04. 22 16:32, Victor Stinner wrote:
 > 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.

[...]

Nick Coghlan argued against that term:

[...]

But I also like “unstable” better than “semi-stable”. Splitting the
internals into “private”/“internal” and “unstable” seems reasonable.


I think picking "semi-stable" would be giving in to the OCD nerd in all 
of us. :-) While perhaps technically less precise, "unstable" is the 
catchy name with the right association. (And yes, we should keep it 
stable within bugfix releases, but the name doesn't need to reflect that 
detail.) The "internal API" isn't an API at all (except for CPython core 
developers and contributors). The "unstable API" would definitely be an 
*API* for users outside the core.


So let's please go with "unstable".



Thanks, you worded that perfectly!

Alright, the PEP now uses “unstable” rather than “semi-stable”. And I 
don't see any issues with the technical details, so I'll see if it can 
still get into Python 3.11. Hopefully Pablo agrees as the Release Manager.

Thanks for the discussion, everyone!
___
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/L6IGXJ5OM2GHAFTAEWWB35STT3MBQL2J/
Code of Conduct: http://python.org/psf/codeofconduct/