On 09. 02. 22 20:04, Stefan Behnel wrote:
Guido van Rossum schrieb am 09.02.22 um 19:36:
On Wed, Feb 9, 2022 at 9:41 AM Pablo Galindo Salgado wrote:
On Wed, 9 Feb 2022 at 17:38, Stefan Behnel wrote:
Pablo Galindo Salgado schrieb am 09.02.22 um 17:40:
Should there be a getter/setter for
On Thu, Feb 10, 2022 at 10:28 AM Petr Viktorin wrote:
> Ah, I've also wanted anonymous unions in the past!
> There's a little problem in that they're not valid in C++, so we can't
> have them in public headers.
>
> We'll need to mention C++ if we update the standard.
IMO we only have to care
On Thu, Feb 10, 2022 at 10:58 AM Petr Viktorin wrote:
>
> On 09. 02. 22 21:41, Gregory P. Smith wrote:
> >
> > On Wed, Feb 9, 2022 at 8:54 AM Victor Stinner > Perhaps use a hybrid approach
> > when feasible similar to:
> >#define PyUnicode_CHECK_INTERNED(op)
> >
On 09. 02. 22 21:41, Gregory P. Smith wrote:
On Wed, Feb 9, 2022 at 8:54 AM Victor Stinner
[...]
Two differing examples from that PR 31221:
Hold off as unsafe for now: Macros that do things like
(PyWhateverObject*)(op) such as PyUnicode_CHECK_INTERNED(op) should not
have the casting part
Petr Viktorin schrieb am 10.02.22 um 11:22:
So, should there be a mechanism to set source/lineno/position on
tracebacks/exceptions, rather than always requiring a frame for it?
There's "_PyTraceback_Add()" currently, but it's incomplete in terms of
what Cython would need.
As it stands,
Hello!
Thanks for the decision, the points raised mostly make sense to me.
However, I find myself and a few others are a little confused by point 2. I
can read it as saying the following perhaps slightly contradictory things:
"It's good that PEP 677 is conservative and sticks to things
On 2/10/22 1:45 PM, Brett Cannon wrote:
> Protocols would let folks rely on a common Path object API w/o having to
require the object
> come from pathlib itself or explicitly subclass something (which I admit
would be rare, but
> there's no reason to artificially constrain this either). Now
On Thu, Feb 10, 2022 at 3:32 AM Shantanu Jain
wrote:
> Hello!
>
>
> Thanks for the decision, the points raised mostly make sense to me.
> However, I find myself and a few others are a little confused by point 2. I
> can read it as saying the following perhaps slightly contradictory things:
>
>
>
On Feb 10, 2022, at 14:26, jeff@autodesk.com wrote:
> We need to be able to produce both arm64 and x86_64 builds of cpython on a
> single machine. I can see that, by default, it chooses the target
> architecture based on the current running architecture. The docs say that we
> can target
On Wed, Feb 9, 2022 at 11:59 AM Barney Gale wrote:
> Penny for your thoughts on those questions, Brett? Protocols are new to
> me. I see importlib.abc.Traversable is a Protocol, and I'm giving PEP 544 a
> read now.
>
Protocols would let folks rely on a common Path object API w/o having to
Hi -
Newbie post here...
We need to be able to produce both arm64 and x86_64 builds of cpython on a
single machine. I can see that, by default, it chooses the target architecture
based on the current running architecture. The docs say that we can target one
platform from the other, but it's
Thanks, Ned. I'm glad I didn't just miss it. I have built a universal binary,
and it looks straightforward to extra the separate ARCHs out with lipo.
Thanks for the response.
Jeff
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send
I created a poll on Discourse:
https://discuss.python.org/t/move-the-pythoncapi-compat-project-under-the-github-python-or-psf-organization/13651
It will be closed automatically in 10 days.
Victor
___
Python-Dev mailing list -- python-dev@python.org
To
On 2022-02-10 2:58 p.m., Victor Stinner wrote:
Would it make sense to move the pythoncapi_compat project under the
GitHub Python or PSF organization to make it more "official" and a
little bit more sustainable?
I think that makes sense. Extensions typically have this kind of
compatibility
Hi,
Would it make sense to move the pythoncapi_compat project under the
GitHub Python or PSF organization to make it more "official" and a
little bit more sustainable?
"The pythoncapi_compat project can be used to write a C extension
supporting a wide range of Python versions with a single code
Hi,
This is a follow-up RFC on PR #30520 (BPO 46337) with regard to urllib's
potentially inflexible scheme-based URL manipulation. In my ticket, I
proposed supplementing the hard-coded uses_* scheme lists that control
URL parsing and joining behavior with an optional enum set that may
override
On Thu, Feb 10, 2022 at 10:23:59PM -0700, Lincoln Auster wrote:
> This is a follow-up RFC on PR #30520 (BPO 46337) with regard to urllib's
...
> It's been about a month since I wrote that PR, and it was marked stale a
> day or two ago. Would anyone be willing to give it a look for feedback
> and
On 10. 02. 22 0:30, Inada Naoki wrote:
On Thu, Feb 10, 2022 at 3:49 AM Brett Cannon wrote:
On Wed, Feb 9, 2022 at 4:19 AM Petr Viktorin wrote:
On 09. 02. 22 4:39, h.vetin...@gmx.com wrote:
That's an interesting idea -- what's keeping us from C11?
No one asking before, probably because
18 matches
Mail list logo
