[Python-Dev] Re: Descriptions in unittest and avoiding confusion
On 5/04/22 4:27 am, Coyot Linden (Glenn Glazer) wrote: On 4/4/22 09:25, Paul Moore wrote: I'm confused, what's wrong with """..."""? Triple quoted strings are not exclusively for docstrings... Paul That isn't my reading of PEP 257, I would be happy to be wrong about this. PEP 257 recommends that all docstrings be triple quoted, not that all triple quoted strings be docstrings. There is a difference! -- 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/KZ2RJE7REYOYPVLOTACILLTYRJXIBPKP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Make HAMT available to python script
Thanks for the reminder Victor. 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/ Note that that was ten years ago -- so maybe worth revisiting. The outcome of this PEP was the addition of the types.MappingProxy > type (previously, it already existed but it was somehow hidden: > type(int.__dict__)). > It's interesting to read the justification for the rejection, among other things: "According to Raymond Hettinger, use of frozendict is low." Then it goes on to provide examples. And of course, the MappingProxy type is used for class dicts, and exposed for other code to use. However, what strikes me is that the list of reasons we don't need an immutable dict is jsu that -- it isn't strictly necessary -- which is not the same as it not being useful. And the MappingProxy is heavier weight and can't be hashed (i.e. used as a key in a dict or put in a set) In the last ten years, we have seen this brought up over and over again -- there really are quite a few use cases. I would love to see PEP 416 reconsidered. (note: it would need a touch of editing to cover the fact that dicts are now ordered) -CHB > > 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/IQMBELHLSWSEYQI7BEPTJTYP47BWTBUV/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ 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/ZHA54FFDVILXGBBP2TVTA2JEYTO3LJCW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone
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 may need a PEP (like PEP 674), but IMO it's good to keep this goal in mind. Otherwise, it's not easy to understand the rationale for changes like https://peps.python.org/pep-0674/ "PEP 674 – Disallow using macros as l-values". 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/3FYHB74CF6XBADFRLUVFV6NUZKXRSBSY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API
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 "semi-stable" API > category for use cases that are intrinsically coupled to implementation > details that may change between feature releases, but should remain stable > within a release series. > > The concrete motivating example for the new category is the extra APIs you > need in order to provide an alternative eval loop implementation. > > The internal API category doesn't properly cover that case, as the APIs there > are free to change even in maintenance releases, and setting Py_BUILD_CORE > exposes a lot more than what an alternative eval loop would need. > > Regular public functions may work in some cases, but aren't necessarily > practical in others (such as exposing the internal frame details for use in > alternative eval loops). > > From an implementation PoV, my own suggestion would be to define a new API > tier with an opt-in macro rather than relying solely on documentation or > naming conventions. > > For example, define "Py_SEMI_STABLE_API" to opt in, with the headers under > "Include/cpython/semi_stable/" (I don't like "unstable" as potential > terminology here, since the internal API is already unstable - we're > splitting the difference between that and the long term stability of the full > public API) For me an API is either stable (remains the same forever) or unstable (change time to time). Public API means: stable, documented, tested. Internal API means: unstable, not documented, not tested. I'm not convinced that it's worth it to create something in the middle. If you want to add doc and tests, it should become a public stable API. For example, IMO PyCode_New() (C API) and types.CodeType constructor (Python API) should be moved to the internal C API, likely with a deprecation period. Cython should not use it but a new stable API. 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/LFE4OV3NYWR4GBMCISZ3H7JH3SEFMX2E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API
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 good. But the
> point of the discussion should've been to continue working with people based
> on the replies rather than proceeding to merge removals of the APIs after
> people said they used them. (echoing Steve and Petr here...)
>
> We discussed this on the steering council today. These APIs were in a weird
> state and despite past decisions at the time of PEP-523 in 2016 they should
> be treated as public-ish rather than entirely private. Because we published a
> document saying "here they are, use them!" and multiple projects have done so
> to good effect.
>
> For 3.11 we'd like those PRs reverted.
Ok, I created https://github.com/python/cpython/pull/32343 to revert
these two PRs. I will merge it as soon as the Python 3.11 release
manager (Pablo) unblocks the main branch (he is currently preparing
the alpha7 release).
On Fri, Apr 1, 2022 at 12:36 PM Steve Dower wrote:
> I don't see any additional discussion on the bug, and the prevailing
> opinion from actual users of this API is that it probably shouldn't
> change,
>From what I understood my change basically only impacts "pydevd"
users. Fabio who works on that project said that he was fine with
that change ("I'm ok with changes"):
https://mail.python.org/archives/list/python-dev@python.org/message/XPDT55ANVKHGG74D62HDBOFLC4EXWJ26/
debugpy, ptvsd, PyDev, PyCharm and VSCode Python use the same code
base: https://github.com/fabioz/PyDev.Debugger
Jason Ansel of TorchDynamo was worried that the API couldn't be used
anymore. I replied that the API remains available. It's just about
adding a few lines of code (that I provided).
For me, all impacted users were made aware and joined the discussion.
It's very rare to be able to reach *all* users impacted by an
incompatible C API change!
If I understood correctly, all questions were replied. For example,
yes, the API remains accessible (with additional code), but no, sadly
the API is not stable (can change at each 3.x.0 major release, but
should not change in 3.x.y bugfix release).
On Fri, Apr 1, 2022 at 12:36 PM Steve Dower wrote:
> and certainly shouldn't become internal without additional
> guarantees about stability.
The discussed API is not stable, Brett repeated that. The internal API
is not stable on purpose. I missed the discussion proposing to design
a stable API for PEP 523.
PEP 523 users are that the API is unstable and seem to be used to
update their code at each major (3.x) Python releases. I'm not
surprised that a debugger which requires a fast low-level access to
Python internals require that.
Or are you talking about not breaking the API in 3.x.y bugfix
releases? Currently, it's an unwritten rule. IMO it's well respected
by all core devs who understand that it's important to not break any
API, including private and internal APIs, in minor bugfix releases. My
changes are unrelated to that.
On Fri, Apr 1, 2022 at 1:24 PM Petr Viktorin wrote:
> Now, the people who'd like a non-breaking solution will now need rush to
> develop and merge one until the next release, or the API breaks for
> users and it'll be too late to do anything about it.
We are talking about two projects (pydevd and TorchDynamo) and there
are 6 months until Python 3.11 final release (PEP 664). We are still
at the alpha phase, no? I don't see why a change only affecting two
projects is a big deal, knowing that these two projects have been made
aware, and I offered a patch that they can apply right now. They don't
need to wait for next October to apply my patch.
Anyway, I will revert my changes (once the main branch is unblocked)
to apply the SC's decision.
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/TUKA6R7VFIKAWBA2XA7QRNXKGKXDH3WG/
Code of Conduct: http://python.org/psf/codeofconduct/
