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

[MRAB]

On 2022-04-30 03:17, Greg Ewing wrote:

On 30/04/22 5:25 am, MRAB wrote:

I was going to suggest "metastable". Too late? :-)


What, the API is balanced on a knife edge and likely to collapse
into something else if you sneeze too hard?

There's a possibility that the universe might be metastable, so a 
metastable API might not be that big a deal.

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

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

[Greg Ewing]

On 30/04/22 5:25 am, MRAB wrote:

I was going to suggest "metastable". Too late? :-)


What, the API is balanced on a knife edge and likely to collapse
into something else if you sneeze too hard?

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

[Python-Dev] Re: Proto-PEP part 4: The wonderful third option

[Guido van Rossum]

 FWIW, Carl presented a talk about his proposed way forward using PEP 649
with some small enhancements to handle cases like dataclasses (*), and it
was well received by those present. I personally hope that this means the
end of the "forward class declarations" proposals (no matter how
wonderful), but the final word is up to the SC.

(*) Mostly fixing the edge cases of the "eval __code__ with tweaked
globals" hack that Carl came up with previously, see
https://github.com/larryhastings/co_annotations/issues/2#issuecomment-1092432875
.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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

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

[Glenn Linderman]

On 4/29/2022 11:42 AM, Stephen J. Turnbull wrote:

MRAB writes:
  > On 2022-04-29 18: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.
  > >  >
  > >  > Honestly, I would be more comfortable with the name: "unstable 
API".
  > >  > It would be clear that the API *can* change often. People who want 
to
  > >  > know exactly the backward compatibility warranties can dig into the
  > >  > API documentation to learn more about it.
  > >  >
  > >  > "Unstable API" is also the name the Guido proposed for
  > > PyCode_New() last year:
  > >  >
  > >  > * Proposal: declare "unstable APIs"
  > >  >
  > > 
https://mail.python.org/archives/list/python-dev@python.org/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/
  > > 

  > >  > * Making code object APIs unstable
  > >  >
  > > 
https://mail.python.org/archives/list/python-dev@python.org/thread/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/
  > > 

  > >  >
  > >  > Victor
  > >
  > >
  > > Nick Coghlan argued against that term:
  > >
  > >  > "unstable" is the wrong term. We already have an unstable API
  > > tier: the
  > >  > internal API, which can change even in maintenance releases. The
  > > value of
  > >  > the new tier is that it is "semi stable": stable in maintenance
  > > releases,
  > >  > unstable in feature releases.
  > >
  > > —
  > > 
https://mail.python.org/archives/list/python-dev@python.org/message/CTKKTHUV5R2A2RRN5DM32UQFNC42DDGJ/
  > > 

  > >
  > >
  > > 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".
  > >
  > I was going to suggest "metastable". Too late? :-)
A
Bikeshedding to a new level! --+


Metabikeshedding...


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

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Denis Kotov]

> From huge codebase experience with C++, it does not cause
significantly better (1) Readabillity or (2) Maintainability on its own
compared to C

I would argue with you on that ...
RAII is fundamental C++ feature that improves Maintainability !!
Also readability is much better because you work with object that will be 
compiled in the same code if you will write it by hands, for example: 
std::vector
___
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/CZF33DKRTAMNVIDAZD2BPVVK4PVCVYM6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephen J. Turnbull]

MRAB writes:
 > On 2022-04-29 18: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.
 > >  >
 > >  > Honestly, I would be more comfortable with the name: "unstable API".
 > >  > It would be clear that the API *can* change often. People who want 
 > > to
 > >  > know exactly the backward compatibility warranties can dig into the
 > >  > API documentation to learn more about it.
 > >  >
 > >  > "Unstable API" is also the name the Guido proposed for
 > > PyCode_New() last year:
 > >  >
 > >  > * Proposal: declare "unstable APIs"
 > >  >
 > > 
 > > https://mail.python.org/archives/list/python-dev@python.org/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/
 > > 
 > > 
 > >  > * Making code object APIs unstable
 > >  >
 > > 
 > > https://mail.python.org/archives/list/python-dev@python.org/thread/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/
 > > 
 > > 
 > >  >
 > >  > Victor
 > > 
 > > 
 > > Nick Coghlan argued against that term:
 > > 
 > >  > "unstable" is the wrong term. We already have an unstable API
 > > tier: the
 > >  > internal API, which can change even in maintenance releases. The
 > > value of
 > >  > the new tier is that it is "semi stable": stable in maintenance
 > > releases,
 > >  > unstable in feature releases.
 > > 
 > > —
 > > 
 > > https://mail.python.org/archives/list/python-dev@python.org/message/CTKKTHUV5R2A2RRN5DM32UQFNC42DDGJ/
 > > 
 > > 
 > > 
 > > 
 > > 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".
 > > 
 > I was going to suggest "metastable". Too late? :-)
   A
Bikeshedding to a new level! --+
___
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/CGNNVU7CUB4U6TK33FSYVIGP7OPPG4XJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

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:
  open7146 ( +0)
  closed 51841 ( +0)
  total  58987 ( +0)

Open issues with patches: 2890 


Most recent 15 issues with no replies (15)
==

#47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin
https://bugs.python.org/issue47258

#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256

#47253: LOAD_GLOBAL instruction with wrong source position
https://bugs.python.org/issue47253

#47252: socket.makefile documentation is missing data regarding the 'b
https://bugs.python.org/issue47252

#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251

#47244: email.utils.formataddr does not respect double spaces
https://bugs.python.org/issue47244

#47242: Annoying white bar in IDLE (line 457 in sidebar.py)
https://bugs.python.org/issue47242

#47241: [C API] Move the PyCodeObject structure to the internal C API 
https://bugs.python.org/issue47241

#47238: Python threading.Event().wait() depends on the system time
https://bugs.python.org/issue47238

#47236: Document types.CodeType.replace() changes about co_exceptionta
https://bugs.python.org/issue47236

#47228: Document that na??ve datetime objects represent local time
https://bugs.python.org/issue47228

#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222

#47219: asyncio with two interpreter instances
https://bugs.python.org/issue47219

#47218: adding name to lzmafile
https://bugs.python.org/issue47218

#47217: adding name to BZ2File
https://bugs.python.org/issue47217



Most recent 15 issues waiting for review (15)
=

#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256

#47255: Many broken :meth: roles in the docs
https://bugs.python.org/issue47255

#47254: enhanced dir?
https://bugs.python.org/issue47254

#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251

#47243: Duplicate entry in 'Objects/unicodetype_db.h'
https://bugs.python.org/issue47243

#47233: show_caches option affects code positions reported by dis.get_
https://bugs.python.org/issue47233

#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222

#47218: adding name to lzmafile
https://bugs.python.org/issue47218

#47217: adding name to BZ2File
https://bugs.python.org/issue47217

#47216: adding mtime option to gzip open()
https://bugs.python.org/issue47216

#47215: Add "unstable" frame stack api
https://bugs.python.org/issue47215

#47208: Support libffi implementations that cannot support invocations
https://bugs.python.org/issue47208

#47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
https://bugs.python.org/issue47205

#47200: Add ZipInfo.mode property
https://bugs.python.org/issue47200

#47199: multiprocessing: micro-optimize Connection.send_bytes() method
https://bugs.python.org/issue47199
___
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/RUVCN7UD4CAO6DUJ3VGRGBYOCM64HR5T/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[MRAB]

On 2022-04-29 18: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.
 >
 > Honestly, I would be more comfortable with the name: "unstable API".
 > It would be clear that the API *can* change often. People who want to
 > know exactly the backward compatibility warranties can dig into the
 > API documentation to learn more about it.
 >
 > "Unstable API" is also the name the Guido proposed for
PyCode_New() last year:
 >
 > * Proposal: declare "unstable APIs"
 >

https://mail.python.org/archives/list/python-dev@python.org/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/


 > * Making code object APIs unstable
 >

https://mail.python.org/archives/list/python-dev@python.org/thread/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/


 >
 > Victor


Nick Coghlan argued against that term:

 > "unstable" is the wrong term. We already have an unstable API
tier: the
 > internal API, which can change even in maintenance releases. The
value of
 > the new tier is that it is "semi stable": stable in maintenance
releases,
 > unstable in feature releases.

—

https://mail.python.org/archives/list/python-dev@python.org/message/CTKKTHUV5R2A2RRN5DM32UQFNC42DDGJ/




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


I was going to suggest "metastable". Too late? :-)
___
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/5B7ES3BZJTKORNCT6LWLRHM7UNSFCKYU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Victor Stinner]

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

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

[Guido van Rossum]

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.
> >
> > Honestly, I would be more comfortable with the name: "unstable API".
> > It would be clear that the API *can* change often. People who want to
> > know exactly the backward compatibility warranties can dig into the
> > API documentation to learn more about it.
> >
> > "Unstable API" is also the name the Guido proposed for PyCode_New() last
> year:
> >
> > * Proposal: declare "unstable APIs"
> >
> https://mail.python.org/archives/list/python-dev@python.org/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/
> > * Making code object APIs unstable
> >
> https://mail.python.org/archives/list/python-dev@python.org/thread/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/
> >
> > Victor
>
>
> Nick Coghlan argued against that term:
>
> > "unstable" is the wrong term. We already have an unstable API tier: the
> > internal API, which can change even in maintenance releases. The value of
> > the new tier is that it is "semi stable": stable in maintenance releases,
> > unstable in feature releases.
>
> —
>
> https://mail.python.org/archives/list/python-dev@python.org/message/CTKKTHUV5R2A2RRN5DM32UQFNC42DDGJ/
>
>
> 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".

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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

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

[Petr Viktorin]

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.

Honestly, I would be more comfortable with the name: "unstable API".
It would be clear that the API *can* change often. People who want to
know exactly the backward compatibility warranties can dig into the
API documentation to learn more about it.

"Unstable API" is also the name the Guido proposed for PyCode_New() last year:

* Proposal: declare "unstable APIs"

https://mail.python.org/archives/list/python-dev@python.org/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/
* Making code object APIs unstable

https://mail.python.org/archives/list/python-dev@python.org/thread/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/

Victor



Nick Coghlan argued against that term:


"unstable" is the wrong term. We already have an unstable API tier: the
internal API, which can change even in maintenance releases. The value of
the new tier is that it is "semi stable": stable in maintenance releases,
unstable in feature releases.


— 
https://mail.python.org/archives/list/python-dev@python.org/message/CTKKTHUV5R2A2RRN5DM32UQFNC42DDGJ/



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

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

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

[Victor Stinner]

> 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 to just a mention
in the *documentation* that this API is "unstable"? It would come with
a link to definition of the "unstable" C API: explain that it can
change in 3.x.y bugfix releases, not not in 3.x.0 releases (major?
minor? I never recall how they should be called).

For now, I don't think that there is a need to actively remove this
API from the "default" Python API and add an opt-in option to get
access to these functions. But having a mention just in the
documentation would be better than nothing.

It seems to be popular complain and request. For example, most of the
ast module would fall into this "unstable API". Previous discussions:

* Proposal: declare "unstable APIs"
   
https://mail.python.org/archives/list/python-dev@python.org/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/
* Making code object APIs unstable
   
https://mail.python.org/archives/list/python-dev@python.org/thread/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/

On one side, it's important to communicate that the API *can* change
in 3.x.0 releases, but also provide some warranties that the API *must
not change* in 3.x.y bugfix releases.

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

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

[Victor Stinner]

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 that the API *can* change often. People who want to
know exactly the backward compatibility warranties can dig into the
API documentation to learn more about it.

"Unstable API" is also the name the Guido proposed for PyCode_New() last year:

* Proposal: declare "unstable APIs"
   
https://mail.python.org/archives/list/python-dev@python.org/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/
* Making code object APIs unstable
   
https://mail.python.org/archives/list/python-dev@python.org/thread/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/

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

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

[Victor Stinner]

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

Another data point is that I mentioned that pybind11 is an important
project for Python ecosystem. This project name and its definition
refer to C++11: "pybind11: Seamless operability between C++11 and
Python".

So far, the only C++ code used in Python is the very recent change
that I made to use reinterpret_cast<> and static_cast<> in the Python
C API (.h header files). The C code base of Python is, well, written
only in C.

I mentioned nullptr if we get compiler warnings on the NULL constant
in static inline functions. nullptr was added by C++11.

I also mentioned C++20 "module" keyword and explained that it doesn't
affect the Python C API.

Having believes and assumptions about C++ compatibility is one thing.
My plan is more about actually *testing it* ;-)

Victor

On Fri, Apr 29, 2022 at 12:36 AM  wrote:
>
> > Not for me to answer, I'm not a proponent of the change.  I'm sure if
> > you read past discussions here and on Discourse you'll find answers
> > from the people who studied the problem carefully.
>
> The opening mail proposed C++11 without rationale or references. I did search
> the archives and discourse before, but nothing stood out, and I don't think an
> encyclopedic knowledge of past python-dev discussions is a reasonable
> requirement to comment or propose a variation on its merits.
>
> > I thought you might have something to add to the conversation, but I guess 
> > not?
>
> I find this tone quite out-of-place. I made a proposal (based on compiler 
> support,
> version hygiene and compatibility with newer standards), and I'd have been 
> more
> than happy to hear arguments (like Antoine's) or references for the merits of
> preferring C++11 (though, again, the point became moot since Victor correctly
> pointed out we can test against several versions).
>
> Still, the insinuation (as it arrives on my end) that I shouldn't participate
> seems really unnecessary.
>
> 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/7SSI53EDU2U565O2TYRTU4CPYLVXPO5K/
> 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/HV6AV527HVU6REWNFABYFLNV6CHGJ6RN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Decreasing refcount for locals before popping frame

[Thomas Grainger]

Can you ping me on the airflow PR for this change? (@graingert)

On Fri, Apr 29, 2022, 7:54 AM Malthe  wrote:

> On Fri, 29 Apr 2022 at 06:50, Thomas Grainger  wrote:
> > You can use a `__del__` method that warns on collection - like an
> unawaited coroutine
> >
> > Also if you're in control of importing the dagfile you can record all
> created dags and report any that are missing from the globals of the module
>
> Yes and I think this is the best we can do given how frames are being
> cleared.
>
> We can notify the user that a DAG was instantiated and not exposed at
> the top-level which is almost guaranteed to be a mistake. There's
> probably no good way currently to do better (for some value of
> "better").
>
> Thanks
>
___
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/QEYZLMYN4OIV4Q7JTIBP7RHEI37QPJAS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Decreasing refcount for locals before popping frame

[Thomas Grainger]

Does this only apply to DAGfiles? Eg
https://airflow.apache.org/docs/apache-airflow/1.10.12/concepts.html#scope

You can use a `__del__` method that warns on collection - like an unawaited
coroutine

Also if you're in control of importing the dagfile you can record all
created dags and report any that are missing from the globals of the module


On Fri, Apr 29, 2022, 7:45 AM Malthe  wrote:

> On Fri, 29 Apr 2022 at 06:38, Thomas Grainger  wrote:
> > Can you show a run-able example of the successful and unsuccessful usage
> of `with DAG(): ... `?
>
> from airflow import DAG
>
> # correct:
> dag = DAG("my_dag")
>
> # incorrect:
> DAG("my_dag")
>
> The with construct really has nothing to do with it, but it is a
> common source of confusion:
>
> # incorrect
> with DAG("my_dag"):
> ...
>
> It is less obvious (to some) in this way that the entire DAG will not
> be picked up. You will in fact have to write:
>
> # correct
> with DAG("my_dag") as dag:
> ...
>
> This way, you're capturing the DAG in the top-level scope which is the
> requirement.
>
___
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/PC3ZTY3COHM3XDOPO3KWWC3NYVCQ7SNH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Decreasing refcount for locals before popping frame

[Malthe]

On Fri, 29 Apr 2022 at 06:50, Thomas Grainger  wrote:
> You can use a `__del__` method that warns on collection - like an unawaited 
> coroutine
>
> Also if you're in control of importing the dagfile you can record all created 
> dags and report any that are missing from the globals of the module

Yes and I think this is the best we can do given how frames are being cleared.

We can notify the user that a DAG was instantiated and not exposed at
the top-level which is almost guaranteed to be a mistake. There's
probably no good way currently to do better (for some value of
"better").

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

[Python-Dev] Re: Decreasing refcount for locals before popping frame

[Malthe]

On Fri, 29 Apr 2022 at 06:38, Thomas Grainger  wrote:
> Can you show a run-able example of the successful and unsuccessful usage of 
> `with DAG(): ... `?

from airflow import DAG

# correct:
dag = DAG("my_dag")

# incorrect:
DAG("my_dag")

The with construct really has nothing to do with it, but it is a
common source of confusion:

# incorrect
with DAG("my_dag"):
...

It is less obvious (to some) in this way that the entire DAG will not
be picked up. You will in fact have to write:

# correct
with DAG("my_dag") as dag:
...

This way, you're capturing the DAG in the top-level scope which is the
requirement.
___
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/HREOTTGPB5JMLGYMIQL4VR2DFI6GBG5J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Decreasing refcount for locals before popping frame

[Thomas Grainger]

Can you show a run-able example of the successful and unsuccessful usage of
`with DAG(): ... `?

On Fri, Apr 29, 2022, 6:31 AM Malthe  wrote:

> Pablo Galindo Salgado wrote:
> > As it has been mentioned there is no guarantee that your variable will
> even
> > be finalized (or even destroyed) after the frame finishes. For example,
> if
> > your variable goes into a reference cycle for whatever reason it may not
> be
> > cleared until a GC run happens (and in some situations it may not even be
> > cleared at any point).
>
> I think there is a reasonable guarantee in CPython that it will happen
> exactly when you leave the frame, assuming there are no cycles or other
> references to the object. There's always the future, but I don't see a very
> near future where this will change fundamentally.
>
> Relying too much on CPython's behavior is a bad thing, but I think there
> are cases where it makes sense and can be a pragmatic choice. Certainly
> lots of programs have successfully relied on `sys._getframe` over the years.
> ___
> 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/BVO7RMMZ2LJFEG4GRNNTYZU3Q4P3DHV3/
> 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/PK7XVKSI7MSU6IJQIQCWM7BHNO7UT5YW/
Code of Conduct: http://python.org/psf/codeofconduct/