On Wed, Dec 15, 2021 at 3:07 AM Victor Stinner wrote:
> I wrote https://bugs.python.org/issue39511 and
> https://github.com/python/cpython/pull/18301 to have per-interpreter
> None, True and False singletons. My change is backward compatible on
> the C API: you can still use "Py_None" in your C
On Wed, Dec 15, 2021 at 2:21 AM Antoine Pitrou wrote:
>
> 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
Whoops, never mind, I see that you started the "immortal objects"
thread to discuss this.
On Tue, Dec 14, 2021 at 4:54 PM Nathaniel Smith wrote:
>
> How did you end up solving the issue where Py_None is a static global
> that's exposed as part of the stable C ABI?
>
>
How did you end up solving the issue where Py_None is a static global
that's exposed as part of the stable C ABI?
On Tue, Dec 14, 2021 at 9:13 AM 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 work to be done but
On Thu, Oct 7, 2021 at 7:54 PM Sam Gross wrote:
> Design overview:
> https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit
Whoa, this is impressive work.
I notice the fb.com address -- is this a personal project or something
facebook is working on? what's the
On Tue, Sep 28, 2021 at 12:40 AM Guido van Rossum wrote:
>
> What I have heard repeatedly, from people who are paid to know, is that most
> users don’t care about the latest features, and would rather stick to a
> release until it becomes unsupported. (Extreme example: Python 2.)
>
> Numpy
On Sun, Sep 26, 2021 at 3:38 AM wrote:
> Open3D is an example. Will finally move to Python 3.9 some time the coming
> month. Its dependency graph contains about 70 other packages.
>
> In this specific case, the underlying problem was that TensorFlow was stuck
> at 3.8. The TensorFlow codebase
On Sat, Sep 25, 2021 at 5:40 PM wrote:
> PyPI packages and wheels are targeted to specific Python versions, which
> means that any project that depends on some of the larger extension packages
> (of which there are many, and many of which are must-have for many projects)
> now start lagging
Was this post intended to go to python-dev or...?
On Mon, Aug 16, 2021 at 9:53 AM Brett Cannon wrote:
>
> https://mail.python.org/archives/list/python-dev@python.org/thread/JRFJ4QH7TR35HFRQWOYPPCGOYRFAXK24/
>
> I can't be objective with Marco as I believe we have recorded issues with him
>
On Thu, Jul 29, 2021 at 4:52 PM Nick Coghlan wrote:
>
> On Fri, 30 Jul 2021, 6:05 am Mark Shannon, wrote:
>>
>> Hi Nick,
>>
>> Our discussion on PEP 558 got me thinking
>> "What is the simplest thing that would work?".
>>
>> This is what I came up (in the form of a draft PEP):
>>
On Tue, Jun 22, 2021 at 4:42 AM Sebastian Rittau wrote:
>
> Am 22.06.21 um 10:00 schrieb Tiziano Zito:
> > I think it is important to notice that GitHub actively blocks user
> > registration and activity from countries that are sanctioned by the US
> > government. At least in 2019 GitHub was
On Wed, May 19, 2021 at 7:28 PM Pablo Galindo Salgado
wrote:
>>
>> Excellent point! Do you know how reliable this is in practice, i.e.
>> what proportion of bytecode source spans are something you can
>> successfully pass to ast.parse? If it works it's obviously nicer, but
>> I can't tell how
On Tue, May 18, 2021 at 2:49 PM Pablo Galindo Salgado
wrote:
> * It actually doesn't have more advantages. The current solution in the PEP
> can do exactly the same as this solution if you allow reparsing when
> displaying tracebacks. This is because with the start line, end line, start
>
On Mon, May 17, 2021 at 6:18 AM Mark Shannon wrote:
> 2. Repeated binary operations on the same line.
>
> A single location can also be clearer when all the code is on one line.
>
> i1 + i2 + s1
>
> PEP 657:
>
> i1 + i2 + s1
>
>
> Using a single location:
>
> i1 + i2 + s1
>
On Fri, May 7, 2021 at 8:14 PM Neil Schemenauer wrote:
>
> On 2021-05-07, Pablo Galindo Salgado wrote:
> > Technically the main concern may be the size of the unmarshalled
> > pyc files in memory, more than the storage size of disk.
>
> It would be cool if we could mmap the pyc files and have the
On Thu, May 6, 2021 at 2:17 AM Nathaniel Smith wrote:
>
> On Thu, Apr 29, 2021 at 9:14 AM Yury Selivanov
> wrote:
> > Nathaniel, at this point it's clear that this thread somehow does not
> > help us understand what you want. Could you please just write your own
> >
On Thu, Apr 29, 2021 at 9:14 AM Yury Selivanov wrote:
> Nathaniel, at this point it's clear that this thread somehow does not
> help us understand what you want. Could you please just write your own
> PEP clearly outlining your proposal, its upsides and downsides?
> Without a PEP from you this
On Fri, Apr 23, 2021 at 4:08 AM Irit Katriel wrote:
>
> On Fri, Apr 23, 2021 at 9:22 AM Nathaniel Smith wrote:
>> I'm not trying to filibuster here -- I really want some form of EGs to
>> land.
>
> I'm very glad to hear that. It's been hard to know where you stand, be
@asyncio.coroutine and @types.coroutine are different beasts.
@asyncio.coroutine is the deprecated one; @types.coroutine is
lower-level and not deprecated.
On Mon, Apr 26, 2021 at 2:48 PM Luciano Ramalho wrote:
>
> I don't understand how it's possible to "Deprecate @coroutine for sake
> of async
On Fri, Apr 23, 2021 at 2:45 AM Chris Angelico wrote:
>
> On Fri, Apr 23, 2021 at 6:25 PM Nathaniel Smith wrote:
> > The main possibility that I don't think we've examined fully is to
> > make 'except' blocks fire multiple times when there are multiple
> > exceptions.
&
?
-- Forwarded message -
From: Hoi lam Poon
Date: Fri, Apr 23, 2021, 02:01
Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]
To: Nathaniel Smith
Stop pretending, I can definitely get the key control file, your working
group, all past actions and instructions
On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum wrote:
> On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith wrote:
>> Sure. This was in my list of reasons why the backwards compatibility
>> tradeoffs are forcing us into awkward compromises. I only elaborated
>> on it b/c i
On Tue, Apr 20, 2021 at 3:15 AM Irit Katriel wrote:
> On Tue, Apr 20, 2021 at 2:48 AM Nathaniel Smith wrote:
>>
>>
>> The problem is that most of the time, even if you're using concurrency
>> internally so multiple things *could* go wrong at once, only one thing
>
On Tue, Apr 20, 2021 at 2:15 PM srku...@mail.de wrote:
>
> So, forgive me my relatively simple mental model about ExceptionGroup. I
> still try to create one for daily use.
>
> As noted in the discussion, an EG provides a way to collect exceptions from
> different sources and raise them as a
On Tue, Apr 20, 2021 at 10:07 AM Mark Shannon wrote:
>
> Hi everyone,
>
> Once upon a time Python was a purely duck typed language.
>
> Then came along abstract based classes, and some nominal typing starting
> to creep into the language.
>
> If you guarded your code with `isinstance(foo,
On Mon, Apr 5, 2021 at 9:48 AM Irit Katriel wrote:
> On Mon, Apr 5, 2021 at 11:01 AM Nathaniel Smith wrote:
>> - I'm uncomfortable with how in some contexts we treat EG's as placeholders
>> for the contained exceptions, and other places we treat them like a single
>> f
OK, better late than never... here's a much-delayed review of the PEP.
Thank you Irit and Guido for carrying this forward while I've been AWOL!
It's fantastic to see my old design sketches turned into something like,
actually real.
== Overall feelings ==
Honestly, I have somewhat mixed feelings
On Fri, Feb 26, 2021 at 5:05 AM Irit Katriel wrote:
> I'm not sure it's safe to assume that it is necessarily a programming error,
> and that the interpreter can essentially break the program in this case.
> Is this not allowed?
>
> try:
> try:
> obj.func()# function that raises
On Thu, Feb 25, 2021 at 10:23 PM Glenn Linderman wrote:
> So then why do you need except* at all? Only to catch unwrapped
> ExceptionGroup before it gets wrapped?
>
> So why not write except ExceptionGroup, and let it catch unwrapped
> ExceptionGroup?
>
> That "CUTE BIT" could be done only
On Thu, Feb 25, 2021 at 2:13 PM Guido van Rossum wrote:
>
> So is "fail-fast if you forget to handle an ExceptionGroup" really a feature?
> (Do we call this out in the PEP?)
>
> We may believe that "except Exception" is an abuse, but it is too common to
> dismiss out of hand. I think if some
On Thu, Jan 28, 2021 at 9:03 PM Gregory P. Smith wrote:
>
> On Thu, Jan 28, 2021 at 10:52 AM Charalampos Stratakis
> wrote:
>>
>>
>>
>> - Original Message -
>> > From: "Mark Shannon"
>> > To: "Python Dev"
>> > Sent: Thursday, January 28, 2021 5:26:37 PM
>> > Subject: [Python-Dev] Why
Hi Mark,
This sounds really cool. Can you give us more details? Some questions that
occurred to me while reading:
- You're suggesting that the contractor would only be paid if the desired
50% speedup is achieved, so I guess we'd need some objective Python
benchmark that boils down to a single
It was decided to leave out 'yield from' support for async generators,
at least for now, due to the implementation complexity. And non-empty
returns in generators are only intended for use with 'yield from', so
they got left out as well.
On Mon, Aug 24, 2020 at 4:48 PM Paul Bryan wrote:
>
> Per
On Mon, Jun 29, 2020 at 5:04 AM Paul Sokolovsky wrote:
>
> Hello,
>
> On Mon, 29 Jun 2020 14:35:08 +0300
> "Jim F.Hilliard" wrote:
>
> > I believe I'm not the only one with this question but, how is Strunk &
> > White connected with white supremacy?
>
> I wouldn't be surprised if the only
On Mon, Jun 29, 2020 at 2:31 AM Steve Holden wrote:
> The commit message used, however, reveals implementation details of the
> change which are irrelevant to the stated aim, which is making the
> documentation clear and concise. Use of such language is certainly
> regrettable, since it
On Wed, Jun 3, 2020 at 2:10 PM Victor Stinner wrote:
> For the short term, my plan is to make structure opaque in the limited
> C API, before breaking more stuff in the public C API :-)
But you're also breaking the public C API:
https://github.com/MagicStack/immutables/issues/46
On Mon, May 25, 2020 at 1:25 AM Serhiy Storchaka wrote:
>
> 24.05.20 17:48, Eric V. Smith пише:
> > Does anyone have an opinion on https://bugs.python.org/issue39673? It
> > maps ETIME to TimeoutError, in addition to the already existing ETIMEDOUT.
> >
> >
On Fri, May 8, 2020 at 12:30 AM Sebastian Krause wrote:
>
> Guido van Rossum wrote:
> > Is there some kind of optimized communication possible yet between
> > subinterpreters? (Otherwise I still worry that it's no better than
> > subprocesses -- and it could be worse because when one
> >
On Wed, May 6, 2020 at 2:34 PM Paul Ganssle wrote:
> I think I tried something similar for tests that involved an environment
> variable and found that it doesn't play nicely with coverage.py at all.
This is a solvable problem:
https://coverage.readthedocs.io/en/coverage-5.1/subprocess.html
On Wed, May 6, 2020 at 7:52 AM Paul Ganssle wrote:
>
> As part of PEP 399, an idiom for testing both C and pure Python versions of a
> library is suggested making use if import_fresh_module.
>
> Unfortunately, I'm finding that this is not amazingly robust. We have this
> issue:
On Wed, May 6, 2020 at 10:03 AM Antoine Pitrou wrote:
>
> On Tue, 5 May 2020 18:59:34 -0700
> Nathaniel Smith wrote:
> > On Tue, May 5, 2020 at 3:47 PM Guido van Rossum wrote:
> > >
> > > This sounds like a significant milestone!
> > >
> >
On Wed, May 6, 2020 at 5:41 AM Victor Stinner wrote:
>
> Hi Nathaniel,
>
> Le mer. 6 mai 2020 à 04:00, Nathaniel Smith a écrit :
> > As far as I understand it, the subinterpreter folks have given up on
> > optimized passing of objects, and are only hoping to do optimized
On Tue, May 5, 2020 at 3:47 PM Guido van Rossum wrote:
>
> This sounds like a significant milestone!
>
> Is there some kind of optimized communication possible yet between
> subinterpreters? (Otherwise I still worry that it's no better than
> subprocesses -- and it could be worse because when
On Mon, Apr 20, 2020 at 6:21 PM Eric Snow wrote:
>
> Nathaniel,
>
> Your tone and approach to this conversation concern me. I appreciate
> that you have strong feelings here and readily recognize I have my own
> biases, but it's becoming increasingly hard to draw any constructive
> insight from
On Mon, Apr 20, 2020 at 5:36 PM Edwin Zimmerman wrote:
>
> On 4/20/2020 7:33 PM, Nathaniel Smith wrote:
> > On Mon, Apr 20, 2020 at 4:26 PM Edwin Zimmerman
> > wrote:
> >> On 4/20/2020 6:30 PM, Nathaniel Smith wrote:
> >>> We already have robus
On Mon, Apr 20, 2020 at 4:26 PM Edwin Zimmerman wrote:
>
> On 4/20/2020 6:30 PM, Nathaniel Smith wrote:
> > We already have robust support for threads for low-isolation and
> > subprocesses for high-isolation. Can you name some use cases where
> > neither of these are app
On Fri, Apr 17, 2020 at 3:57 PM Eric Snow wrote:
>
> On Fri, Apr 17, 2020 at 2:59 PM Nathaniel Smith wrote:
> > I think some perspective might be useful here :-).
> >
> > The last time we merged a new concurrency model in the stdlib, it was
> > asyncio.
>
On Fri, Apr 17, 2020 at 11:50 AM Eric Snow wrote:
> Dilemma
>
>
> Many folks have conflated PEP 554 with having a per-interpreter GIL.
> In fact, I was careful to avoid any mention of parallelism or the GIL
> in the PEP. Nonetheless some are expecting that when PEP 554 lands we
>
On Wed, Apr 15, 2020 at 2:59 PM Ivan Pozdeev via Python-Dev
wrote:
> "Glom syntax" still excludes the delimiter, whatever it is, from use in keys.
> So it's still a further limitation compared to the JSON spec.
Glom does let you be specific about the exact lookup keys if you want,
to handle
On Tue, Apr 14, 2020 at 9:26 PM David Mertz wrote:
>
> I've written AttributeDict a fair number of times. Each time I write it from
> scratch, which is only a few lines. And I only make a silly wore about 50% of
> the time when I do so.
I've also written it a number of times, and never found a
On Thu, Apr 2, 2020 at 2:48 PM Pablo Galindo Salgado
wrote:
>
> > About the migration, can I ask who is going to (help to) fix projects
> which rely on the AST?
>
> I think you misunderstood: The AST is exactly the same as the old and the new
> parser. The only
> the thing that the new parser
On Sat, Mar 21, 2020 at 11:35 AM Steven D'Aprano wrote:
>
> On Fri, Mar 20, 2020 at 06:18:20PM -0700, Nathaniel Smith wrote:
> > On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
> > wrote:
> > > This is a proposal to add two new methods, ``cutprefix`` and
>
On Fri, Mar 20, 2020 at 11:27 AM Victor Stinner wrote:
> I would prefer to continue to experiment passing tstate explicitly in
> internal C APIs until most blocker issues will be fixed. Once early
> work on running two subinterpreters in parallel will start working
> (one "GIL" per interpreter),
On Fri, Mar 20, 2020 at 11:54 AM Dennis Sweeney
wrote:
> This is a proposal to add two new methods, ``cutprefix`` and
> ``cutsuffix``, to the APIs of Python's various string objects.
The names should use "start" and "end" instead of "prefix" and
"suffix", to reduce the jargon factor and for
> > On 09/12/2019 2:15 pm, Chris Angelico wrote:
> You: "We should limit things. Stuff will be faster."
> Others: "Really? Because bit masking is work. It'll be slower."
> You: "Maybe we limit it somewhere else, whatever. It'll be faster."
> Others: "Will it? How much faster?"
> You: "It'll be
On Thu, Dec 5, 2019 at 5:38 AM Mark Shannon wrote:
> From my limited googling, linux has a hard limit of about 600k file
> descriptors across all processes. So, 1M is well past any reasonable
> per-process limit. My impression is that the limits are lower on
> Windows, is that right?
Linux does
On Tue, Dec 3, 2019 at 8:20 AM Mark Shannon wrote:
> The Python language does not specify limits for many of its features.
> Not having any limit to these values seems to enhance programmer freedom,
> at least superficially, but in practice the CPython VM and other Python
> virtual
> machines
On Mon, Nov 18, 2019 at 4:41 PM Pablo Galindo Salgado
wrote:
>
> Hi,
>
> What do people feel about exposing Tools/parser/unparse.py in the standard
> library? Here is my initial rationale:
>
> * The tool already needs to be maintained and updated as is tested as part of
> the test suite.
> * I
On Sun, Nov 17, 2019 at 1:58 PM Nick Coghlan wrote:
> On Sat., 16 Nov. 2019, 8:26 am 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 1
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 motivation for this change seems a bit unclear to
me.
I guess the
On Mon, Sep 23, 2019 at 1:30 PM Vinay Sajip via Python-Dev
wrote:
>
> OK - but that's just one I picked at random. There are others like it - what
> would be the process for deciding which ones need to be made private and
> moved? Should an issue be raised to track this?
There are really two
On Mon, Sep 23, 2019, 08:28 Vinay Sajip via Python-Dev <
python-dev@python.org> wrote:
> > requires some newer tools like -fvisibility=hidden that work
> > differently across different platforms, and so far no-one's done the
> > work to sort out the details.
>
> I've started looking at this, but
On Fri, Sep 20, 2019 at 2:58 PM Vinay Sajip via Python-Dev
wrote:
>
> > > Right, I'm pretty sure that right now Python doesn't have any way to
> > share symbols between .c files without also exposing them in the C
> > API.
>
> On other C projects I've worked on, the public API is expressed in one
On Fri, Sep 20, 2019 at 1:00 PM Andrew Svetlov wrote:
> This target is very important for keeping public API as small as possible.
Right, I'm pretty sure that right now Python doesn't have any way to
share symbols between .c files without also exposing them in the C
API.
This is fixable using
On Fri, Aug 9, 2019 at 12:07 PM wrote:
>
> Eric V. Smith wrote:
> > Hopefully the warnings in 3.9 would be more visible that what we saw in
> > 3.7, so that library authors can take notice and do something about it
> > before 3.10 rolls around.
> > Eric
>
> Apologies for the ~double-post on the
On Tue, Aug 6, 2019 at 3:44 PM Brett Cannon wrote:
> I think this is a good example of how the community is not running tests with
> warnings on and making sure that their code is warnings-free. This warning
> has existed for at least one full release and fixing it doesn't require some
> crazy
On Fri, May 31, 2019 at 11:39 AM Barry Warsaw wrote:
>
> On May 31, 2019, at 01:22, Antoine Pitrou wrote:
>
> > I second this.
> >
> > There are currently ~7000 bugs open on bugs.python.org. The Web UI
> > makes a good job of actually being able to navigate through these bugs,
> > search
I wouldn't mind having a little more breathing room. It's frustrating
to miss the train, but these bugs are several decades old so I guess
nothing terrible will happen if their fixes get delayed to 3.9.
On Thu, May 30, 2019 at 4:23 PM Nick Coghlan wrote:
>
> Hi folks,
>
> The reference
On Tue, May 28, 2019 at 5:24 PM Greg Ewing wrote:
>
> Terry Reedy wrote:
> > I believe that the situation is or can be thought of as this: there is
> > exactly 1 function locals dict. Initially, it is empty and inaccessible
> > (unusable) from code. Each locals() call updates the dict to a
On Tue, May 28, 2019 at 6:48 PM Greg Ewing wrote:
>
> Nathaniel Smith wrote:
> > - [proxy]: Simply return the .f_locals object, so in all contexts
> > locals() returns a live mutable view of the actual environment:
> >
> > def locals():
> > return get_
On Tue, May 28, 2019 at 6:02 PM Guido van Rossum wrote:
>
> On Tue, May 28, 2019 at 5:25 PM Greg Ewing
> wrote:
>>
>> Terry Reedy wrote:
>> > I believe that the situation is or can be thought of as this: there is
>> > exactly 1 function locals dict. Initially, it is empty and inaccessible
>> >
On Mon, May 27, 2019 at 9:18 PM Guido van Rossum wrote:
>
> Note that the weird, Action At A Distance behavior is also visible for
> locals() called at module scope (since there, locals() is globals(), which
> returns the actual dict that's the module's __dict__, i.e. the Source Of
> Truth. So
On Mon, May 27, 2019 at 9:16 AM Guido van Rossum wrote:
>
> I re-ran your examples and found that some of them fail.
>
> On Mon, May 27, 2019 at 8:17 AM Nathaniel Smith wrote:
[...]
>> The interaction between f_locals and and locals() is also subtle:
>>
>> def f(
First, I want to say: I'm very happy with PEP 558's changes to
f_locals. It solves the weird threading bugs, and exposes the
fundamental operations you need for debugging in a simple and clean
way, while leaving a lot of implementation flexibility for future
Python VMs. It's a huge improvement
On Sat, May 25, 2019, 07:38 Guido van Rossum wrote:
> This looks great.
>
> I only have two nits with the text.
>
> First, why is the snapshot called a "dynamic snapshot"? What exactly is
> dynamic about it?
>
It's dynamic in that it can spontaneously change when certain other events
happen.
On Thu, May 23, 2019 at 2:18 PM Brett Cannon wrote:
> I'm personally viewing it as a first step in addressing the maintenance
> burden we have with such a large stdlib. Christian started this work over a
> year ago and I think it's worth seeing through. After that we should probably
> have a
On Fri, May 24, 2019, 08:08 Ben Cail wrote:
>
> Why not have the PSF hire someone (or multiple people) to be paid to
> work on the maintenance burden? This could be similar to the Django
> fellows:
> https://www.djangoproject.com/fundraising/#who-is-the-django-fellow. It
> seems like a good
On Wed, May 22, 2019, 04:32 Christian Heimes wrote:
> On 22/05/2019 12.19, Steven D'Aprano wrote:
> > I don't think this PEP should become a document about "Why you should
> > use PAM". I appreciate that from your perspective as a Red Hat security
> > guy, you want everyone to use best practices
On Wed, May 22, 2019, 12:14 Sean Wallitsch
wrote:
> Dear python-dev,
>
> I'm writing to provide some feedback on PEP-594, primarily the proposed
> deprecation and reason for the removal of the aifc and audioop libraries.
>
> The post production film industry continues to make heavy use of AIFFs,
On Tue, May 21, 2019 at 4:25 AM Victor Stinner wrote:
>
> Le mar. 21 mai 2019 à 13:18, André Malo a écrit :
> > There's software in production using both. (It doesn't mean it's on pypi or
> > even free software).
> >
> > What would be the maintenance burden of those modules anyway? (at least for
On Tue, May 21, 2019 at 10:43 AM Glenn Linderman wrote:
> After maintaining my own version of http.server to fix or workaround some of
> its deficiencies for some years, I discovered bottle.py. It has far more
> capability, is far better documented, and is just as quick to deploy. While I
>
On Thu, May 16, 2019 at 1:23 PM Victor Stinner wrote:
>
> Le jeu. 16 mai 2019 à 20:58, Petr Viktorin a écrit :
> > I always thought the classic (exc_type, exc_value, exc_tb) triple is a
> > holdover from older Python versions, and all the information is now in
> > the exception instance.
> > Is
On Thu, May 16, 2019 at 2:13 PM Pablo Galindo Salgado
wrote:
> I propose to remove finally the parser module as it has been "deprecated" for
> a long time, is almost clear that nobody uses it and has very limited
> usability and replace it (maybe with a different name)
> with pgen2 (maybe with
On Thu, May 16, 2019 at 2:17 PM Steve Dower wrote:
> You go on to say "pass an error message" and "keep repr(obj) if you
> want", but how is this different from creating an exception that
> contains the custom message, the repr of the object, and chains the
> exception that triggered it?
A
On Thu, May 16, 2019, 09:07 Steve Dower wrote:
>
> Actually, if the default implementation prints the exception message,
> how is this different from sys.excepthook? Specifically, from the point
> of customizing the hooks.
>
sys.excepthook means the program has fully unwound and is about to
On Wed, May 15, 2019 at 6:25 PM Victor Stinner wrote:
> I proposed a different approach: add a new sys.unraisablehook hook
> which is called to handle an "unraisable exception". To handle them
> differently, replace the hook. For example, I wrote a custom hook to
> log these exceptions into a
I don't care about the deprecation either way. But can we fix the
individual decorators so both orders work? Even if it requires a special
case in the code, it seems worthwhile to remove a subtle user-visible
footgun.
On Wed, May 15, 2019, 12:39 Ethan Furman wrote:
> In issue 11610*
On Mon, Apr 29, 2019 at 5:01 PM Neil Schemenauer wrote:
> As far as I understand, we have a similar problem already for
> gc.get_objects() because those static type objects don't have a
> PyGC_Head. My 2-cent proposal for fixing things in the long term
> would be to introduce a function like
On Sat, Apr 27, 2019, 04:27 Armin Rigo wrote:
> Hi Neil,
>
> On Wed, 24 Apr 2019 at 21:17, Neil Schemenauer
> wrote:
> > Regarding the Py_TRACE_REFS fields, I think we can't do them without
> > breaking the ABI because of the following. For GC objects, they are
> > always allocated by
You don't necessarily need rpath actually. The Linux loader has a
bug/feature where once it has successfully loaded a library with a given
soname, then any future requests for that soname within the same process
will automatically return that same library, regardless of rpath settings
etc. So as
On Tue, Apr 23, 2019, 05:09 Andrew Svetlov wrote:
> I agree that `from typing import TYPE_CHECKING` is not desirable from
> the import time reduction perspective.
>
> From my understanding code completion *can* be based on type hinting
> to avoid actual code execution.
> That's why I've
On Sat, Apr 20, 2019 at 2:11 PM Inada Naoki wrote:
>
> "import typing" is slow too.
Many static analysis tools will also accept:
TYPE_CHECKING = False
if TYPE_CHECKING:
...
At least mypy and pylint both treat all variables named TYPE_CHECKING
as true, regardless of where they came from.
On Mon, Apr 15, 2019 at 8:58 PM Michael Sullivan wrote:
>
> On Mon, Apr 15, 2019 at 4:06 PM Nathaniel Smith wrote:
>>
>> On Mon, Apr 15, 2019, 15:27 Michael Sullivan wrote:
>>>
>>> > The main question is if anyone ever used Py_TRACE_REFS
On Mon, Apr 15, 2019 at 5:00 PM Michael Sullivan wrote:
>
> I've submitted PEP 591 (Adding a final qualifier to typing) for discussion to
> typing-sig [1].
I'm not on typing-sig [1] so I'm replying here.
> Here's the abstract:
> This PEP proposes a "final" qualifier to be added to the
On Mon, Apr 15, 2019, 15:27 Michael Sullivan wrote:
> > The main question is if anyone ever used Py_TRACE_REFS? Does someone
> > use sys.getobjects() or PYTHONDUMPREFS environment variable?
>
> I used sys.getobjects() today to track down a memory leak in the
> mypyc-compiled version of mypy.
>
>
On Fri, Apr 12, 2019 at 5:05 PM Steve Dower wrote:
>
> On 12Apr.2019 1643, Nathaniel Smith wrote:
> > On Thu, Apr 11, 2019 at 8:26 AM Steve Dower wrote:
> >>
> >> On 10Apr2019 1917, Nathaniel Smith wrote:
> > I don't know how many people use Py_TRACE_R
On Thu, Apr 11, 2019 at 8:26 AM Steve Dower wrote:
>
> On 10Apr2019 1917, Nathaniel Smith wrote:
> > It sounds like --with-pydebug has accumulated a big grab bag of
> > unrelated features, mostly stuff that was useful at some point for
> > some CPython dev trying to de
On Thu, Apr 11, 2019 at 8:32 AM Serhiy Storchaka wrote:
> On other hand, since using the debug allocator doesn't cause problems
> with compatibility, it may be possible to use similar technique for the
> objects double list. Although this is not easy because of objects placed
> at static memory.
On Wed, Apr 10, 2019 at 1:50 PM Steve Dower wrote:
>
> On 10Apr2019 1227, Nathaniel Smith wrote:
> > On Wed, Apr 10, 2019, 04:04 Victor Stinner > <mailto:vstin...@redhat.com>> wrote:
> > I don't think that I ever used sys.getobjects(), whereas many projects
>
On Wed, Apr 10, 2019, 04:04 Victor Stinner wrote:
> Le mar. 9 avr. 2019 à 22:16, Steve Dower a écrit
> :
> > What are the other changes that would be required?
>
> I don't know.
>
> > And is there another
> > way to get the same functionality without ABI modifications?
>
> Py_TRACE_REFS is a
1 - 100 of 440 matches
Mail list logo
