On 15/07/2022 16:09, Rob Boehne via Python-Dev wrote:
100% agree – dealing with 5 or more platforms for discussion groups is
a nightmare, and I tend not to follow any of them as closely for that
reason.
I agree. I don't mind having to use Discourse if I want to take part in
a discussion but 99
On 05/10/2021 07:59, Nick Coghlan wrote:
On Tue, 28 Sep 2021, 6:55 am Brett Cannon, wrote:
On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev <
python-dev@python.org> wrote:
However the stable ABI is still a second class citizen as it is still
not possible (AFAIK) to spe
On 27/09/2021 21:53, Brett Cannon wrote:
On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev <
python-dev@python.org> wrote:
On 26/09/2021 05:21, Steven D'Aprano wrote:
[snip]
> These are not rhetorical questions, I genuinely do not know. I *think*
> that there
On 26/09/2021 05:21, Steven D'Aprano wrote:
[snip]
As for the C-API... Python is 30 years old. Has it ever had a stable
C-API before now? Hasn't it *always* been the case that C packages have
targetted a single version and need to be rebuilt from source on every
release?
No.
These are not r
On 02/02/2021 23:08, Greg Ewing wrote:
On 3/02/21 4:52 am, Phil Thompson wrote:
Thanks - that's fairly definitive, although I don't really understand
why __new__ has this particular requirement.
The job of tp_new is to initialise the C struct. To do this,
it first has to initialise the fields
On 02/02/2021 14:18, Greg Ewing wrote:
On 3/02/21 12:07 am, Phil Thompson wrote:
On 01/02/2021 23:50, Greg Ewing wrote:
At the C level, there is always a *single* inheritance hierarchy.
Why?
Because a C struct can only extend one other C struct.
Yes - I misunderstood what you meant by "at
ll object.__new__().
(If you want us to change the code, please file a bpo bug report. I
know
that's no fun, but it's the way to get the right people involved.)
Happy to do that but I first wanted to check if I was doing something
"silly" - I'm still not sure.
On 01/02/2021 23:50, Greg Ewing wrote:
On 2/02/21 12:13 am, Phil Thompson via Python-Dev wrote:
TypeError: object.__new__(B) is not safe, use B.__new__()
It's not safe because object.__new__ doesn't know about any
C-level initialisation that A or B need.
But A.__new__ is call
Hi,
I'm trying to understand the purpose of the check in tp_new_wrapper() of
typeobject.c that results in the "is not safe" exception.
I have the following class hierarchy...
B -> A -> object
...where B and A are implemented in C. Class A has an implementation of
tp_new which does a few con
On 28/12/2020 11:27, Inada Naoki wrote:
On Mon, Dec 28, 2020 at 7:22 PM Phil Thompson
wrote:
> So I'm +1 to make Unicode simple by removing PyUnicode_READY(), and -1
> to make Unicode complicated by adding customizable callback for lazy
> population.
>
> Anyway, I am OK to un-deprecate PyUnico
On 28/12/2020 02:07, Inada Naoki wrote:
On Sun, Dec 27, 2020 at 8:20 PM Ronald Oussoren via Python-Dev
wrote:
On 26 Dec 2020, at 18:43, Guido van Rossum wrote:
On Sat, Dec 26, 2020 at 3:54 AM Phil Thompson via Python-Dev
wrote:
That wouldn’t be a solution for code using the PyUnicode_
On 26/12/2020 10:52, Ronald Oussoren via Python-Dev wrote:
On 25 Dec 2020, at 23:03, Nelson, Karl E. via Python-Dev
wrote:
I was directed to post this request to the general Python development
community so hopefully this is on topic.
One of the weaknesses of the PyUnicode implementation is
12 matches
Mail list logo