On 12/28/20 9:31 PM, Guido van Rossum wrote:
Let me see if I can unpack this.
I observe that `type.__new__() ` is really the C function `type_new()` in typeobject.c, and hence I will refer to it by
that name.
I understand that `type_new()` is the only way to create type objects, and it
incl
Issue #42775: https://bugs.python.org/issue42775
PR #23986: https://github.com/python/cpython/pull/23986
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailm
Let me see if I can unpack this.
I observe that `type.__new__() ` is really the C function `type_new()` in
typeobject.c, and hence I will refer to it by that name.
I understand that `type_new()` is the only way to create type objects, and
it includes a call to `__init_subclass__()`.
In the sourc
For the record - the 3rd process that is currently un-customizable when
creating a class, i.e. things that happen in an opaque way inside
`type.__new__`,
is the ABC class machinery. I could not recall it when
writing the previous e-mail.
Still - I think this might be very little disruptive, and ye
IMO it's a feature, not a bug :-)
>>> import enum
>>> class Foo(enum.Enum):
... A = 1
... B = 1.0
...
>>> Foo(1)
>>> Foo(1.0)
>>> Foo.B
See:
https://docs.python.org/dev/library/enum.html#duplicating-enum-members-and-values
"However, two enum members are allowed to have the same value. Gi
On Tue, 29 Dec 2020 02:20:45 +0900
Inada Naoki wrote:
> On Mon, Dec 28, 2020 at 10:53 PM Antoine Pitrou wrote:
> >
> > On Mon, 28 Dec 2020 11:07:46 +0900
> > Inada Naoki wrote:
> > >
> > > Additionally, if we introduce the customizable lazy str object, it's
> > > very easy to release GIL durin
On Mon, Dec 28, 2020 at 10:53 PM Antoine Pitrou wrote:
>
> On Mon, 28 Dec 2020 11:07:46 +0900
> Inada Naoki wrote:
> >
> > Additionally, if we introduce the customizable lazy str object, it's
> > very easy to release GIL during basic Unicode operations. Many third
> > parties may assume PyUnicode
On 27 Dec 2020, at 22:38, Christian Heimes
mailto:christ...@python.org>> wrote:
On 27/12/2020 21.20, Erlend Aasland wrote:
[…]
Who can help me review code that touches the sqlite3 module code base?
as far as I know we don't have an active module owner and maintainer any
more.
What about Berker P
On Mon, 28 Dec 2020 11:07:46 +0900
Inada Naoki wrote:
>
> Additionally, if we introduce the customizable lazy str object, it's
> very easy to release GIL during basic Unicode operations. Many third
> parties may assume PyUnicode_Compare doesn't release GIL if both
> operands are Unicode objects.
> On 28 Dec 2020, at 14:00, Inada Naoki wrote:
>
> On Mon, Dec 28, 2020 at 8:52 PM Phil Thompson
> wrote:
>>
>>
>> I would have thought that an object was defined by its behaviour rather
>> than by any particular implementation detail.
>>
>
> As my understanding, the policy "an object was
On Mon, Dec 28, 2020 at 8:52 PM Phil Thompson
wrote:
>
>
> I would have thought that an object was defined by its behaviour rather
> than by any particular implementation detail.
>
As my understanding, the policy "an object was defined by its
behavior..." doesn't mean "put unlimited amount of imp
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_*
Paul Bryan via Python-Dev writes:
> Should this be considered a bug in the Enum implementation?
Probably not. The underlying implementation of Enums is integers, and
False and True *are* the integers 0 and 1 for most purposes. And it
propagates further. Same example:
>>> class Foo(enum.Enum)
> On 28 Dec 2020, at 03:58, Greg Ewing wrote:
>
> Rather than a full-blown buffer-protocol-like thing, could we
> get by with something simpler? How about just having a flag
> in the unicode object indicating that it doesn't own the
> memory that it points to?
I don’t know about the OP, but fo
15 matches
Mail list logo
