On Fri, Apr 1, 2022 at 4:06 AM Steve Dower wrote:
> The main difference is that 'immutables' offers you a stable/versioned
> interface to use it, while the one that's in CPython is an internal
> implementation detail. If one day we find a better design, we can just
> switch to it, while
By beta 1 things should be stable (modulo bug fixes). But documentation may
lag. If you can’t figure something out by reading the code by all means ask!
On Fri, Apr 1, 2022 at 11:40 Matthieu Dartiailh
wrote:
> As the maintainer of bytecode (thanks to Victor), I expect that adding
> support for
As the maintainer of bytecode (thanks to Victor), I expect that adding
support for 3.11 will be challenging at least. However I hoped that by
waiting for the first beta most changes would be at least documented. What
would be the best channel to reach people that may clarify how things work
ACTIVITY SUMMARY (2022-03-25 - 2022-04-01)
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:
open7153 ( +8)
closed 51763 (+61)
total 58916 (+69)
Open issues
Hi Gabriele,
On 01/04/2022 4:50 pm, Gabriele wrote:
Does this mean that this line in the bytecode library is likely to fail with
3.11, with no way to fix it?
You can pass the exception table the same way you pass all the other arguments.
The exception table depends on the code, but that is
On Fri, Apr 1, 2022 at 8:56 AM Gabriele wrote:
> Does this mean that this line in the bytecode library is likely to fail
> with 3.11, with no way to fix it?
>
>
> https://github.com/MatthieuDartiailh/bytecode/blob/7b0423234b0e999b45a4eb0c58115b284314f46b/bytecode/concrete.py#L398
>
Yes, that
Does this mean that this line in the bytecode library is likely to fail
with 3.11, with no way to fix it?
https://github.com/MatthieuDartiailh/bytecode/blob/7b0423234b0e999b45a4eb0c58115b284314f46b/bytecode/concrete.py#L398
On Fri, 1 Apr 2022, 10:40 Victor Stinner, wrote:
> I created
Hi,
On 22/03/2022 6:07 pm, Victor Stinner wrote:
Hi,
I proposed two PRs to move the private C API (Include/cpython/) of PEP
523 "Adding a frame evaluation API to CPython" to the internal C API
(Include/internals/):
* https://github.com/python/cpython/pull/32052
*
Hi, Steve. Thanks for your detailed explanation. Indeed I already saw the
API discussion in PEP 603. It's much easier to make the decision in a
third-party library. I think we will be fine with the immutables library.
On Fri, Apr 1, 2022 at 7:05 PM Steve Dower wrote:
> On 4/1/2022 11:48 AM,
On 01. 04. 22 11:01, Victor Stinner wrote:
Hi,
Update on this issue: I merged my 2 PRs.
https://bugs.python.org/issue46850
The following APIs have been moved to the internal C API:
- _PyFrameEvalFunction type
- _PyInterpreterState_GetEvalFrameFunc()
- _PyInterpreterState_SetEvalFrameFunc()
On 4/1/2022 11:48 AM, zhang kai wrote:
Thanks Victor and Pablo. I will check the discussion of PEP 603. It's a
little weird to use the immutables library when it's code in already in
CPython but I'm glad it's an option.
The main difference is that 'immutables' offers you a stable/versioned
Thanks Victor and Pablo. I will check the discussion of PEP 603. It's a
little weird to use the immutables library when it's code in already in
CPython but I'm glad it's an option.
Kai
On Fri, Apr 1, 2022 at 6:14 PM Pablo Galindo Salgado
wrote:
> You may want to check PEP 603, which more or
On 4/1/2022 10:01 AM, Victor Stinner wrote:
Update on this issue: I merged my 2 PRs.
https://bugs.python.org/issue46850
So what was the point of this discussion then?
I don't see any additional discussion on the bug, and the prevailing
opinion from actual users of this API is that it
You may want to check PEP 603, which more or less proposes this (the author
of the pep is the author of the HAMT code)
check https://peps.python.org/pep-0603/
Alternatively, there is already a pypi package with this code:
https://pypi.org/project/immutables/
Regards from cloudy London,
Pablo
Hi,
In 2019, Yury Selivanov, who added HAMT and contextvars to Python,
wrote PEP 603 "Adding a frozenmap type to collections":
https://peps.python.org/pep-0603/
Sadly, the PEP was stuck in discussions:
*
https://discuss.python.org/t/pep-603-adding-a-frozenmap-type-to-collections/2318
*
I created https://bugs.python.org/issue47185 to discuss this issue:
either recompute automatically co_exceptiontable, or at least document
the change.
Victor
On Fri, Apr 1, 2022 at 11:21 AM Victor Stinner wrote:
>
> ("Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython"
> private
Hi,
HAMT is a very useful immutable mapping type. Currently CPython use it
internally to implement contextvar. Considering immutable data structure is
very useful I hope we can make it available to python script(maybe via
collections module).
Immutable data structures are fundamental parts of
("Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython"
private C API to the internal C API")
On Fri, Apr 1, 2022 at 11:01 AM Chris Angelico wrote:
>
> On Fri, 1 Apr 2022 at 19:51, Victor Stinner wrote:
> > In Python, sadly the types.CodeType type also has a public constructor
> >
Hi,
Update on this issue: I merged my 2 PRs.
https://bugs.python.org/issue46850
The following APIs have been moved to the internal C API:
- _PyFrameEvalFunction type
- _PyInterpreterState_GetEvalFrameFunc()
- _PyInterpreterState_SetEvalFrameFunc()
- _PyEval_EvalFrameDefault()
If you use any of
On Fri, 1 Apr 2022 at 19:51, Victor Stinner wrote:
> In Python, sadly the types.CodeType type also has a public constructor
> and many projects break at each Python release because the API
> changes. Hopefully, it seems like the new CodeType.replace() method
> added to Python 3.8 mitigated the
On Wed, Mar 30, 2022 at 5:42 PM Guido van Rossum wrote:
> In the not so distant past I have proposed to introduce a new category,
> "Unstable APIs". These are public but are not guaranteed to be backwards
> compatible in feature releases (though I feel they should remain so in bugfix
>
On Mon, Mar 28, 2022 at 1:44 PM Petr Viktorin wrote:
> Perhaps we need a new "tier" of C API for debuggers -- API that's
> guaranteed stable for a major release, and if it's changed it should
> always break with compile errors (e.g. the function gets a new
> argument), rather than silently change
22 matches
Mail list logo