On Wed, 6 Sep 2017 10:50:11 -0700
Ethan Smith wrote:
> I think this is useful as it can make porting easier. I am using it in my
> attempts to cross compile CPython to WebAssembly (since WebAssembly in its
> MVP does not support threading).
The problem is that the burden of maintenance falls on u
On Wed, 06 Sep 2017 20:18:52 +
"Gregory P. Smith" wrote:
>
> For commonly typed things that get annoying,
>
> #define _Py_grail _PyRuntme.ceval.holy.grail
>
> within the .c source file that does a lot of grail flinging seems fine to
> me.
That sounds fine to me too. Thank you!
Regards
On Thu, 7 Oct 2021 15:52:56 -0400
Sam Gross wrote:
> Hi,
>
> I've been working on changes to CPython to allow it to run without the
> global interpreter lock. I'd like to share a working proof-of-concept that
> can run without the GIL. The proof-of-concept involves substantial changes
> to CPytho
On Sun, 10 Oct 2021 11:19:44 -0300
Facundo Batista wrote:
> Hello everyone!
>
> I need to pack a long list of numbers into shared memory, so I thought
> about using `struct.pack_into`.
>
> Its signature is
>
> struct.pack_into(format, buffer, offset, v1, v2, ...)
>
> I have a long list of
Hello,
It used to be that defining __int__ allowed an object to be accepted as
an integer from various functions, internal and third-party, thanks to
being implicitly called by e.g. PyLong_AsLong.
Today, and since bpo-37999, this is no longer the case. It seems that
__int__ has now become a st
On Thu, 14 Oct 2021 11:52:11 +1300
Greg Ewing wrote:
> On 14/10/21 11:19 am, Greg Ewing wrote:
> > Not really -- __int__ is expected to return something of type
> > int, whereas __trunc__ is expected to return the same type as
> > its operand.
>
> Scratch that, it seems __trunc__ also returns
On Wed, 13 Oct 2021 17:00:49 -0700
Guido van Rossum wrote:
> On Wed, Oct 13, 2021 at 4:56 PM Victor Stinner wrote:
>
> > Honestly, I don't understand well the difference between __int__() and
> > __index__().
> >
> > * https://docs.python.org/dev/reference/datamodel.html#object.__int__
> > * htt
On Thu, 14 Oct 2021 04:24:30 -0500
Eryk Sun wrote:
>
> > Note that PyNumber_Long() is now the only place inside the interpreter
> > calling the `nb_int` slot. But since it also has those undesirable code
> > paths accepting str and buffer-like objects, it's usable in fewer
> > situations than yo
On Fri, 15 Oct 2021 12:36:15 +1100
Steven D'Aprano wrote:
> Hello Doug,
>
> On Thu, Oct 14, 2021 at 03:45:07PM -, Doug Swarin wrote:
>
> > I believe strong and valid arguments can be made about the use of None
> > being a fundamental flaw in some types of coding
>
> Can you elaborate on
On Wed, 20 Oct 2021 02:55:52 +0200
Victor Stinner wrote:
>
> Debug build
> ---
>
> When Python is built in debug mode, most compiler optimizations are
> disabled. For example, Visual Studio disables inlining. Benchmarks must
> not be run on a Python debug build, only on release build: u
Hi Joannah,
On Thu, 21 Oct 2021 13:00:11 -0300
Joannah Nanjekye wrote:
> Last year I opened the following issues, to implement
> int PyObject_CopyToObject() and PyObject *PyObject_GetMemoryView(PyObject
> *obj).
>
> They were meant to be as part of PEP 3118, I wonder if they are worth an
> eff
On Wed, 10 Nov 2021 21:12:17 -0600
Tim Peters wrote:
> [Bob Fang ]
> > This is a modest proposal to consider having sorted containers
> > (http://www.grantjenks.com/docs/sortedcontainers/) in standard library.
>
> +1 from me, but if and only if Grant Jenks (its author) wants that too.
>
> It's
On Thu, 11 Nov 2021 11:01:32 -0800
Richard Levasseur wrote:
>
> In the end, it was a fun exercise, but in practice a dictionary and
> sorted() got me 90% of the way there and sufficed. Optimizing that last 10%
> wasn't worth the effort.
>
> Anyways, I came to two particular, IMHO, conclusions:
>
On Thu, 11 Nov 2021 20:58:29 +
Bob Fang wrote:
> Just want to mention that we do have this nice website to look at, although I
> am not sure how up to date it is:
>
> https://www.wheelodex.org/projects/sortedcontainers/rdepends/?page=1
Wow, thank you, that is very nice!
Best regards
Antoi
ntoine.
>
> Thanks,
> Bob
>
> > On 11 Nov 2021, at 12:28, Paul Moore wrote:
> >
> > On Thu, 11 Nov 2021 at 11:51, Antoine Pitrou > <mailto:anto...@python.org>> wrote:
> >>
> >> On Wed, 10 Nov 2021 21:12:17 -0600
> >&
On Tue, 23 Nov 2021 18:00:28 +0100
Victor Stinner wrote:
>
> From what I understood, debug builds are mostly used by Python core
> developers to develop Python and so an important use case for
> performance is running the Python test suite.
>
> (1) Replacing macros with static inline functions m
On Thu, 25 Nov 2021 23:51:58 +
Oscar Benjamin wrote:
> >
> > Not a PEP proponent (or even a typing user), but I thought this had
> > been made clear long ago. My understanding is that optional,
> > incremental type hints are and have always been considered the primary
> > use case for annotat
On Mon, 29 Nov 2021 12:32:19 +
Mark Shannon wrote:
> Hi,
>
> I am surprised by the insistence on this thread for excluding comparisons
> from constant folding.
> Why should we special case comparisons? Am I missing something here?
Is it actually special-cased or is it just not implemented?
On Tue, 7 Dec 2021 15:39:25 +0100
Petr Viktorin wrote:
> On 30. 11. 21 19:52, Victor Stinner wrote:
> > On Tue, Nov 30, 2021 at 7:34 PM Guido van Rossum wrote:
> >> How about *not* asking for an exception and just following the PEP 387
> >> process? Is that really too burdensome?
> >
> > T
On Wed, 15 Dec 2021 10:42:17 +0100
Christian Heimes wrote:
> On 14/12/2021 19.19, Eric Snow wrote:
> > A while back I concluded that neither approach would work for us. The
> > approach I had taken would have significant cache performance
> > penalties in a per-interpreter GIL world. The approac
Hi Eric,
Did you try to take into account the envisioned project for adding a
"complete" GC and removing the GIL?
Regards
Antoine.
On Tue, 14 Dec 2021 10:12:07 -0700
Eric Snow wrote:
> Hi all,
>
> I'm still hoping to land a per-interpreter GIL for 3.11. There is
> still a decent amount of
On Wed, 15 Dec 2021 14:13:03 +0100
Antoine Pitrou wrote:
> Hi Eric,
>
> Did you try to take into account the envisioned project for adding a
> "complete" GC and removing the GIL?
Sorry, I was misremembering the details. Sam Gross' proposal
(posted here on 07/1
On Thu, 16 Dec 2021 14:32:05 +1100
Steven D'Aprano wrote:
> On Wed, Dec 15, 2021 at 02:57:46PM -0800, Guido van Rossum wrote:
>
> > Another potential issue is that there may be some applications that take
> > refcounts at face value (perhaps obtained using sys.getrefcount()). These
> > would find
On Tue, 14 Dec 2021 10:38:25 -0700
Eric Snow wrote:
>
> So we (the core devs) would effectively be requiring those extensions
> to support subinterpreters, regardless of letting them opt out. This
> situation has been weighing heavily on my mind since Nathaniel brought
> this up. Here are some
On Thu, 16 Dec 2021 23:32:17 +1100
Steven D'Aprano wrote:
> On Thu, Dec 16, 2021 at 12:23:09PM +0100, Antoine Pitrou wrote:
> >
> > The "real number of references" would not be known for immortal objects.
>
> Oh that surprises me. How does that work? Doe
On Thu, 16 Dec 2021 13:25:53 +0100
Petr Viktorin wrote:
> On 16. 12. 21 12:33, Antoine Pitrou wrote:
> > On Tue, 14 Dec 2021 10:38:25 -0700
> > Eric Snow wrote:
> >>
> >> So we (the core devs) would effectively be requiring those extensions
> >>
On Thu, 16 Dec 2021 11:38:28 -0700
Eric Snow wrote:
> On Thu, Dec 16, 2021 at 4:34 AM Antoine Pitrou wrote:
> > As a data point, in PyArrow, we have a bunch of C++ code that interacts
> > with Python but doesn't belong in a particular Python module. That C++
> > code
On Sat, 18 Dec 2021 08:40:57 -
"Jim J. Jewett" wrote:
> Why are Immutability and transitive Immortality needed to share an object
> across interpreters?
Immutability is a functional requirement: you don't want one
interpreter to be able to change the state of another one by mistake.
Unlike
On Fri, 31 Dec 2021 11:18:34 +
Mark Dickinson wrote:
>
> It looks as though the next step would be to run some integer-intensive
> benchmarks on 32-bit ARM, with both --enable-big-digits=15 and
> --enable-big-digits=30. If those show a win (or at least, not a significant
> loss) for 30-bit di
On Mon, 3 Jan 2022 22:40:25 -0800
"Gregory P. Smith" wrote:
>
> rerunning a mere few of those in --rigorous mode for more runs does not
> significantly improve the stddev so I'm not going to let that finish.
The one benchmark that is bigint-heavy is pidigits AFAIK, so you might
want to re-run th
Hi Christian,
On Sun, 9 Jan 2022 19:39:06 +0100
Christian Heimes wrote:
> Hi,
>
> I would like to remind everybody that Python's support for OpenSSL 3.0
> is preliminary [1]. Python compiles with OpenSSL 3.0.0 and simple code
> kinda works. However there are known performance regressions, mi
Hello,
Currently, a f-string is not recognized as a docstring:
>>> class C: f"foo"
>>> C.__doc__
>>>
This means you need to use a (admittedly easy) workaround:
>>> class C: __doc__ = f"foo"
>>> C.__doc__
'foo'
Shouldn't the former be allowed for convenience?
Regards
Antoine.
___
> discussion about it. See https://bugs.python.org/issue28739 for at least
> part of the discussion.
Ah, sorry for the misunderstanding. While the example I showed doesn't
have any substitutions, I'm interested in the non-trivial (non-constant)
case actually :-)
Regards
Antoine.
&
On Tue, 18 Jan 2022 15:17:41 +0100
Victor Stinner wrote:
> Hi,
>
> My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on
> updating Python 3.10 to Python 3.11 in Fedora, but some specific
> Python 3.11 incompatible changes are causing more troubles than
> others:
> https://discuss.py
On Mon, 7 Feb 2022 15:29:39 +0100
Victor Stinner wrote:
> On Mon, Feb 7, 2022 at 2:26 PM Victor Stinner wrote:
> > CPython is also affected by these issues, but the benefits of PEP 674
> > (alone) are too indirect, so I chose to avoid mentioning CPython
> > issues directly, to avoid confusion.
On Tue, 8 Feb 2022 00:39:12 -0800
"Gregory P. Smith" wrote:
> What does pyperformance say about --enable-optimizations builds with all of
> those compiled out vs today?
>
> I like the runtime safety checking for purposes of making the lives of
> Python C API users easier. But without the use of a
On Tue, 08 Feb 2022 01:12:22 -
"Jim J. Jewett" wrote:
> - Should we require the presence of NaNs in order for CPython to build?
> - Should we require IEEE 754 floating-point for CPython-the-implementation?
> - Should we require IEEE 754 floating-point for Python-the-language?
>
> I don't have
On Wed, 09 Feb 2022 03:39:42 -
h.vetin...@gmx.com wrote:
>
> That is becoming dated quickly, as Microsoft has deprecated, and is removing,
> that version quite rapidly from their CI services (azure/GHA), i.e. mid
> March, see:
> https://github.com/actions/virtual-environments/issues/4312.
>
On Wed, 9 Feb 2022 17:49:19 +0100
Victor Stinner wrote:
> On Wed, Feb 9, 2022 at 1:04 PM Petr Viktorin wrote:
> > > Right now, a large number of macros cast their argument to a type. A
> > > few examples:
> > >
> > > #define PyObject_TypeCheck(ob, type)
> > > PyObject_TypeCheck(_PyObject_CAST(ob)
On Mon, 14 Feb 2022 13:19:00 +0100
Petr Viktorin wrote:
>
> If we don't have much sympathy for projects that use private API where
> does that leave pythoncapi_compat?
If you look at pythoncapi_compat.h, it provides backports for
recently-introduced public APIs such as PyObject_CallOneArg().
R
Hi,
On Thu, 10 Feb 2022 23:58:31 +0100
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'm +1 on this. Many projects maintain their own set of com
On Fri, 18 Feb 2022 14:56:10 -0700
Eric Snow wrote:
> On Wed, Feb 16, 2022 at 11:06 AM Larry Hastings wrote:
> > I experimented with this at the EuroPython sprints in Berlin years ago. I
> > was sitting next to MvL, who had an interesting observation about it.
>
> Classic MvL! :)
>
> > He
On Sat, 19 Feb 2022 12:05:22 -0500
Larry Hastings wrote:
> On 2/19/22 04:41, Antoine Pitrou wrote:
> > On Fri, 18 Feb 2022 14:56:10 -0700
> > Eric Snow wrote:
> >> On Wed, Feb 16, 2022 at 11:06 AM Larry Hastings
> >> wrote:
> >>> He suggested
On Sun, 27 Mar 2022 00:48:04 -
"Itay Yeshaya" wrote:
> When running unittest with the -v flag, if a test has errors, and has a
> docstring, the test name is shown on one line, and the docstring is shown on
> the next line with the `ERROR` word.
> For example:
>
> ./python.exe -m unittest -v
On Wed, 30 Mar 2022 12:03:58 +0100
Steve Dower wrote:
> On 30Mar2022 1124, Barney Gale wrote:
> > I'd like to become a maintainer for the pathlib module, if possible. I
> > know the code and tests inside-out, and I've been wrestling the
> > internals for past few Python releases. I check the bug
On Tue, 5 Apr 2022 22:54:00 +0200
Victor Stinner wrote:
> 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)
If the HPy design is the long term goal, why no
On Sun, 17 Apr 2022 19:00:45 -0700
Guido van Rossum wrote:
> Is it not acceptable to create new functions that return non-named-tuple
> objects (e.g. dataclasses with slots)?
I'd advocate creating a single new function that provides more
structured access to that various information, like we did
On Wed, 20 Apr 2022 12:52:53 +0200
Victor Stinner wrote:
> On Wed, Apr 20, 2022 at 10:03 AM Antoine Pitrou wrote:
> > If the HPy design is the long term goal, why not just recommend that
> > people use HPy? And keep the C API for expert users with specific
> > needs tha
On Tue, 26 Apr 2022 11:46:41 +0200
Victor Stinner wrote:
> I prefer to add an environment variable, only pass the option
> explicitly on the command line.
I don't really understand this sentence, can you rephrase?
___
Python-Dev mailing list -- pytho
riable is an easy to influence a program or system
whose inner workings you don't control (for example a system that
spawns child Python processes). And it sounds like a good idea to allow
that given that it improves security?
Regards
Antoine.
>
> Victor
>
> On Wed, Apr 27,
On Thu, 28 Apr 2022 22:03:25 +0900
"Stephen J. Turnbull" wrote:
> h.vetin...@gmx.com writes:
>
> > While I don't know who proposed C++11 or where, I'd therefore like
> > to propose to move to _at least_ C++14.
>
> What benefits does this have for Python development?
Let me second that quest
As a data point, I don't remember that recent versions of CPython
brought any particular pain for PyArrow, which is a set of bindings
written in Cython around some C++ core library code.
Regards
Antoine.
On Wed, 27 Apr 2022 18:31:13 +0200
Victor Stinner wrote:
> Hi,
>
> If you got issues wi
thon/issues/83536
>
> In fact, after a long study, Python C API is *not* affected by this
> issue. Using "module" remains valid in C++20: see the issue for
> details.
I'm not surprised. The C++ committee takes compatibility extremely
seriously...
Regards
Antoine.
>
On Mon, 2 May 2022 15:21:24 +0200
Victor Stinner wrote:
>
> Slowly, more and more tests can be added. For example, this change fixing
> compiler warnings when passing "const PyObject*" to Python C API functions
> adds tests to _testcppext.cpp:
> https://github.com/python/cpython/pull/92138
Doesn
On Tue, 10 May 2022 16:12:13 +0100
Barney Stratford wrote:
> Hello all.
>
> It occurs to me that creating threads in Python is more awkward than it needs
> to be. Every time I want to start a new thread, I end up writing the same
> thing over and over again:
>
> def target(*args, **kwds):
>
On Mon, 16 May 2022 11:13:56 +0200
Victor Stinner wrote:
> Hi,
>
> I propose adding a new C API to "build an Unicode string". What do you
> think? Would it be efficient with any possible Unicode string storage
> and any Python implementation?
>
> PyPy has an UnicodeBuilder type in Python, but he
On Mon, 16 May 2022 14:22:44 +0200
Victor Stinner wrote:
> On Mon, May 16, 2022 at 2:11 PM Antoine Pitrou wrote:
> > > PyUnicodeBuilder_Init(&builder);
> > >
> > > // Overallocation is more efficient if
On Mon, 30 May 2022 12:53:57 -0700
Guido van Rossum wrote:
> I would love to see header files used for this -- while I know there is a
> long tradition of feature-flags that must be #defined by the user before
> #including a header in order to affect what the header exports (or not!),
> 30 years l
On Thu, 21 Jul 2022 07:59:46 +0200
Stefan Behnel wrote:
> h.vetin...@gmx.com schrieb am 18.07.22 um 18:04:
> > One of the comments in the retro was:
> >> Searching the archives is much easier and have found me many old threads
> >> that I probably would have problem finding before since I haven
On Wed, 17 Aug 2022 19:23:02 +0100
MRAB wrote:
> >>
> >> I do not like introducing escapes which are not supported in other RE
> >> implementations. There is a chance of future conflicts.
> >>
> >> Java broke compatibility in Java 8 by redefining \v from a single
> >> vertical tab character to t
Haven't we migrated to Discourse? This discussion will probably not
have any effects on this mailing-list.
(yes, not everyone likes Discourse, and I'm skeptical as well, but the
decision has been made by now)
On Mon, 17 Oct 2022 09:13:34 -
"Denis Kotov" wrote:
> Stephen J. Turnbull wrote:
On Fri, 02 Dec 2022 18:41:44 -0500
"Gordon R. Burgess" wrote:
> I am a long time lurker here*, a professional and educational user of
> the language, a list moderator with practical exeperience managing a
> engaged community of a few thousand users over the course of a decade -
> and yes, I am old
On Wed, 18 Jan 2023 12:04:41 +0200
Ville Voutilainen via Std-Proposals
wrote:
> On Wed, 18 Jan 2023 at 11:45, Frederick Virchanza Gotham via
> Std-Proposals wrote:
> >
> > I have sent this email to two mailing lists for programming language
> > proposals, the one for C++ and the one for Python. I
It says it's feeling fine ;-)
Regards
Antoine.
On Mon, 09 Sep 2019 14:29:51 +0100
"Benjamin Peterson" wrote:
> Hi all,
> It's finally time to schedule the last releases in Python 2's life. There
> will be two more releases of Python 2.7: Python 2.7.17 and Python 2.7.18.
>
> Python 2.7.17 r
I agree that passing a struct size as struct member values sounds a bit
unidiomatic.
Also, it doesn't achieve ABI stability, just allows erroring out in
case the user links with the wrong Python version.
Regards
Antoine.
On Sun, 29 Sep 2019 16:47:41 +1000
Nick Coghlan wrote:
> On Sat, 28 Se
On Mon, 30 Sep 2019 22:43:40 +0200
Victor Stinner wrote:
> Hi back,
>
> It seems like "config.struct_size = sizeof(PyConfig);" syntax is "not
> really liked".
>
> I don't see any traction to provide a stable ABI for embedded Python.
Not at the last minute in a rc1, I'd say :-)
I think if you w
Did you weigh PEP 602 against PEP 605? Is there a summary of the
strong points you found for each and how you decided for the former?
Thank you
Antoine.
On Wed, 30 Oct 2019 19:26:35 -
"Brett Cannon" wrote:
> On behalf of the steering council I am happy to announce that as
> BDFL-Delegat
On Wed, 13 Nov 2019 14:52:32 +0100
Victor Stinner wrote:
>
> #define _PyRuntimeState_GetThreadState(runtime) \
>
> ((PyThreadState*)_Py_atomic_load_relaxed(&(runtime)->gilstate.tstate_current))
> #define _PyThreadState_GET() _PyRuntimeState_GetThreadState(&_PyRuntime)
>
> _PyThreadState_GET
On Fri, 15 Nov 2019 14:21:53 -0800
Nathaniel Smith wrote:
> As you know, I'm skeptical that PEP 554 will produce benefits that are
> worth the effort, but let's assume for the moment that it is, and
> we're all 100% committed to moving all globals into the threadstate.
> Even given that, the motiv
On Mon, 18 Nov 2019 12:39:00 -0500
Random832 wrote:
> On Mon, Nov 18, 2019, at 05:26, Antoine Pitrou wrote:
> > > For the first goal, I don't think this is possible, or desirable.
> > > Obviously if we remove the GIL somehow then at a minimum we'll need to
>
On Tue, 3 Dec 2019 09:31:22 -0800
Guido van Rossum wrote:
> I think it’s too soon to worry about this. I don’t see a reason to harass
> people who maintain code based that were just recently migrated.
Agreed with Guido. Let's wait a couple more years and rethink it.
Regards
Antoine.
_
On Tue, 10 Dec 2019 00:59:09 +
Oscar Benjamin wrote:
>
> > Note that changing pytest to output fewer lines won't work as we will
> > just hit the bytecode limit instead.
>
> I'm not sure. I think that pytest should have some kind of limit on
> what it produces in this situation.
Agreed. I
On Fri, 6 Dec 2019 13:54:13 +
Rhodri James wrote:
> Apologies again for commenting in the wrong place.
>
> On 05/12/2019 16:38, Mark Shannon wrote:
>
> > Memory access is usually a limiting factor in the performance of
> > modern CPUs. Better packing of data structures enhances locality and
On Fri, 6 Dec 2019 15:19:48 -0800
"Gregory P. Smith" wrote:
> I'd prefer it if we stayed on topic here...
+1. Please take rants about 30-year old CPU designs elsewhere (for
example Hacker News, Twitter, Facebook, etc.).
Regards
Antoine.
___
Python-D
On Mon, 9 Dec 2019 21:42:36 -0500
Kyle Stanley wrote:
> > (b) Why limit coroutines? It's just another Python object and has no
> operating resources associated with it. Perhaps your definition of
> coroutine is different, and you are thinking of OS threads?
>
> This was my primary concern with
On Wed, 11 Dec 2019 23:17:48 -0500
Kyle Stanley wrote:
>
> TL;DR: It's definitely possible to have more than one client per TCP port.
Thanks for correcting me. Not sure why, but I appear to make that
mistake once every couple years.
> I'm have no idea what the
> realistic maximum limit of glob
On Thu, 12 Dec 2019 00:56:41 -0500
Kyle Stanley wrote:
>
> IMO, the max
> number of concurrent transactions that the a database system can handle at
> once is a very clear application of Moore's Law.
I'm not quite sure that's the case. I think in reality Moore's Law has
also helped databases be
On Thu, 12 Dec 2019 11:43:58 +
Rhodri James wrote:
> On 11/12/2019 21:35, Antoine Pitrou wrote:
> > In any case, this will have to be judged on benchmark numbers, once
> > Mark (or someone else) massages the interpreter to experiment with
> > those runtime memory
On Tue, 24 Dec 2019 12:08:33 +0900
"Stephen J. Turnbull" wrote:
> David Mertz writes:
>
> > Even though I was the first person in this thread to suggest
> > collections.OrderedSet, I'm "meh" about it now. As I read more and played
> > with the sortedcollections package, it seemed to me that wh
On Wed, 1 Jan 2020 11:51:41 -0800
"Gregory P. Smith" wrote:
> On Wed, Jan 1, 2020 at 6:40 AM Andrew Svetlov
> wrote:
>
> > __del__ is very useful not for interpreter shutdown but as a regular
> > destructor in object's lifecycle.
> >
>
> The reason we should warn people against ever implement
On Sun, 05 Jan 2020 12:37:24 +1300
Greg Ewing wrote:
> On 5/01/20 11:41 am, Antoine Pitrou wrote:
>
> > +1 for pointing to `weakref.finalize` as a better
> > alternative for things that may survive until interpreter shutdown.
>
> I'm not sure that weakref.finalize
On Thu, 9 Jan 2020 15:12:41 +0100
Victor Stinner wrote:
>
> Getting the interpreter from a Python thread state is trivial: interp
> = tstate->interp.
>
> The problem is how to get the current Python thread state.
> *Currently*, it's an atomic variable. But tomorrow with multiple
> interpreters r
On Mon, 3 Feb 2020 13:18:46 +0100
Petr Viktorin wrote:
> >
> > I agree with the sentiment that gradual deprecations are more easily
> > managed, this statement about Python 3.0 is not true. The unicode
> > transition was never thought to be small, and that's *why* 3.0 was such
> > a big change
On Fri, 07 Feb 2020 14:59:19 +0100
Julien Danjou wrote:
> Hi fellows,
>
> I've been hit by a segfault recently in a binary wheel running on Python
> 3.7.3, but that worked fine on Python 3.7.5.
Can you clarify a bit? Was it with a single specific package, or is it
reproducible with several Pyth
On Wed, 12 Feb 2020 17:22:53 +0100
"mailer@app.tempr.email" wrote:
>
> I've just been looking through the multiprocessing module and open issues and
> wondered why there were some small bugs/patches not being fixed/merged. Is
> this the "normal" patch cycle? Does it take years for bugs to get f
On Mon, 24 Feb 2020 00:30:41 -0500
Kyle Stanley wrote:
> > In that case I'm not sure the author ought to get credit for the PR. They
> can file a bug pointing out the typo and someone else can submit a fix.
>
> That sounds like a reasonable solution to me; even for more substantial
> issues (if
Hi,
On Tue, 25 Feb 2020 11:48:44 -
e2la...@gmail.com wrote:
> Hello,
>
> I have successfully built Python 3.8.1 on QNX, but ran into a problem when
> using 'make -j4'. The build process invariably hangs with multiple
> single-threaded child processes stuck indefinitely waiting on semaphor
Admittedly, the whole distutils spawn code should be rewritten to use
subprocess.
Regards
Antoine.
On Wed, 26 Feb 2020 17:52:53 -
"Elad Lahav" wrote:
> A change to posix_spawnp() fixes the problem for me:
>
> diff --git a/Lib/distutils/spawn.py b/Lib/distutils/spawn.py
> index c
Hi Elad,
Can you open an issue on https://bugs.python.org/ and post your
findings there? I don't think it makes sense to continue discussing
this on python-dev.
(note that opening a bug doesn't mean it will be fixed quickly, but at
least it's recorded somewhere instead of being lost in the mai
On Wed, 11 Mar 2020 11:17:22 +
Barney Gale wrote:
> Hi,
>
> Pathlib's symlink_to() and link_to() methods have different argument
> orders, so:
>
> a.symlink_to(b) # Creates a symlink from A to B
> a.link_to(b) # Creates a hard link from B to A
>
> I don't think link_to() was inten
On Tue, 17 Mar 2020 14:47:19 +
Mark Shannon wrote:
> On 16/03/2020 3:04 pm, Victor Stinner wrote:
> > Hi,
> >
> >> Changes on this scale merit a PEP and proper discussion, rather than
> >> being added piecemeal without proper review.
> >
> > Last November, I asked explicitly on python-de
On Wed, 18 Mar 2020 13:35:16 +
Anders Munch wrote:
> Chris Angelico [mailto:ros...@gmail.com]:
> > And by that logic, globals are even more capable. I don't understand your
> > point. Isn't the purpose of the tstate parameters to avoid the problem of
> > being unable to have multiple tstates w
On Fri, 20 Mar 2020 19:24:22 +0100
Victor Stinner wrote:
>
> One good example is Py_AddPendingCall(). The documentation says that
> it's safe to call it without holding the GIL. Except that right now,
> there is no reliable way to get the correct interpreter in this case
> (correct me if I'm wron
On Fri, 10 Apr 2020 19:20:00 +0200
Victor Stinner wrote:
>
> Note: Cython and cffi should be preferred to write new C extensions.
> This PEP is about existing C extensions which cannot be rewritten with
> Cython.
Using Cython does not make the C API irrelevant. In some
applications, the C API h
On Fri, 10 Apr 2020 23:33:28 +0100
Steve Dower wrote:
> On 10Apr2020 2055, Antoine Pitrou wrote:
> > On Fri, 10 Apr 2020 19:20:00 +0200
> > Victor Stinner wrote:
> >>
> >> Note: Cython and cffi should be preferred to write new C extensions.
> >> Thi
On Sat, 11 Apr 2020 02:11:41 +0200
Victor Stinner wrote:
> Le ven. 10 avr. 2020 à 22:00, Antoine Pitrou a écrit :
> > > Debug runtime and remove debug checks in release mode
> > > .
> > >
> > > If the C e
On Sat, 11 Apr 2020 01:52:13 +0200
Victor Stinner wrote:
>
> By the way, CPython currently uses statically allocated types for
> builtin types like str or list. This may have to change to run
> efficiently multiple subinterepters in parallel: each subinterpeter
> should have its own heap-allocate
On Mon, 13 Apr 2020 11:35:34 +0100
Steve Dower wrote:
>
> Neither Windows not macOS support fork (macOS only recently).
Victor's argument: "fork() is not terrific with inline reference
counts".
My argument: people shouldn't generally use fork() anyway, because it
has other issues.
My statement
On Fri, 17 Apr 2020 13:59:46 -0600
Eric Snow wrote:
> > For bytes or buffer objects, I understand that you propose to share
> > the exact same PyObject objects between interpreters, at least in the
> > first implementation.
> >
> > It may be better to have one proxy object in each interpreter whic
On Sat, 18 Apr 2020 10:08:27 -0600
Eric Snow wrote:
> On Sat, Apr 18, 2020, 01:16 Antoine Pitrou wrote:
>
> > On Fri, 17 Apr 2020 13:59:46 -0600
> > Eric Snow wrote:
> > > > For bytes or buffer objects, I understand that you propose to share
> > > &g
1901 - 2000 of 4909 matches
Mail list logo
