Indeed.
On Tue, May 28, 2019 at 11:07 PM Greg Ewing
wrote:
> Nick Coghlan wrote:
> > Having a single locals() call de-optimize an entire function would be
> > far from ideal.
>
> I don't see what would be so bad about that. The vast majority
> of functions have no need for locals().
>
> --
> Gre
Nick Coghlan wrote:
Having a single locals() call de-optimize an entire function would be
far from ideal.
I don't see what would be so bad about that. The vast majority
of functions have no need for locals().
--
Greg
___
Python-Dev mailing list
Pytho
On 5/28/2019 11:35 PM, Montana Burr wrote:
What is the justification for causing list == 3 to evaluate to False,
besides the obvious "a list cannot equal a number"?
That is completely sufficient. The default comparison is by id, and a
class must override to get something different. The 'def
On Wed., 29 May 2019, 2:29 pm Guido van Rossum, wrote:
> So why is it “hellish” for JITs if locals() returns a proxy, while
> frame.f_locals being a proxy is okay?
>
As I understand it, they already drop out of compiled mode if they detect
that the code is tinkering with frame objects.
Having a
So why is it “hellish” for JITs if locals() returns a proxy, while
frame.f_locals being a proxy is okay?
On Tue, May 28, 2019 at 9:12 PM Nick Coghlan wrote:
> (I'll likely write a more detailed reply once I'm back on an actual
> computer, but wanted to send an initial response while folks in the
Ok, now I'm mildly curious to knpw:
What is the justification for causing list == 3 to evaluate to False,
besides the obvious "a list cannot equal a number"?
On Tue, May 28, 2019 at 9:34 PM Montana Burr wrote:
> Ok, now I'm mildly curious to knpw:
>
> What is the justification for causing list
(I'll likely write a more detailed reply once I'm back on an actual
computer, but wanted to send an initial response while folks in the US are
still awake, as the detailed reply may not be needed)
Thanks for this write-up Nathaniel - I think you've done a good job of
capturing the available design
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 curre
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_caller_frame().f_locals
>
> Not sure I
On 27/05/2019 04:52:17, Montana Burr wrote:
NumPy arrays have this awesome feature, where array == 3 does an
element-wise comparison and returns a list. For example:
np.array([1,2,3,4,5])==3
returns
[False,False,True,False,False]
It would be cool if Python had similar functionality for lis
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
>> >
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_caller_frame().f_locals
Not sure I quite follow this -- as far as I can see, f_locals
currently has the sam
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
> > (unusable) from code. Each locals() call updates the dict to a curren
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 current
snapshot and returns it.
Yes, I understand *what's* happen
On Thu, May 23, 2019 at 10:17 PM Ezio Melotti wrote:
>
> Hello,
> Berker and I have been working on a PEP that suggests we keep using
> and improving bugs.python.org and Roundup instead of switching to
> GitHub Issues as proposed by PEP 581.
>
> The PEP covers:
> * What are the advantages of Round
I made a pull request for this that appears to work fine for my 10x
smaller test case (reduces tear-down time from over 45 seconds to over
7). It implements my second earlier sketch (add a vector of search
fingers, to eliminate searches):
https://github.com/python/cpython/pull/13612
It would be
Congrats to everyone who participated!
Regards
Antoine.
On Tue, 28 May 2019 13:52:53 +0200
Petr Viktorin wrote:
> As BDFL-Delegate, I am accepting PEP 590 -- Vectorcall: a fast calling
> protocol for CPython.
> https://www.python.org/dev/peps/pep-0590/
>
> There was a major last-minute cha
On Sun, 26 May 2019 at 00:37, 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?
The dynamic part comes in if you call locals() twice: because it
returns the same ma
Thank you Petr for being a great BDFL-Delegate, and thanks to Mark and
Jeroen for working together. And thanks to everyone else who participated
in the discussion. Good luck with the implementation and the follow-up
steps!
--Guido
On Tue, May 28, 2019 at 4:55 AM Petr Viktorin wrote:
> As BDFL-D
As BDFL-Delegate, I am accepting PEP 590 -- Vectorcall: a fast calling
protocol for CPython.
https://www.python.org/dev/peps/pep-0590/
There was a major last-minute change to the text (though one that was
discussed since PyCon US): The API is not finalized yet, and it's
provided using private
On Tue, May 28, 2019 at 08:37:17AM +0100, Paul Moore wrote:
> Of course, all of this is only if we have decided to formalise the
> semantics and change CPython to conform. I've never personally been
> affected by any of the edge cases with locals(), so on a purely
> personal basis, I'm equally hap
I'm guessing the reason is to remove the overhead of keeping the dictionary
up to date during function execution when no Python code needs access to it.
On Mon, May 27, 2019 at 8:10 PM Richard Damon
wrote:
> On 5/27/19 2:05 PM, Terry Reedy wrote:
> > On 5/27/2019 9:52 AM, Richard Damon wrote:
>
On Tue, 28 May 2019 at 06:00, Nathaniel Smith wrote:
> - There's the "justified" action-at-a-distance that currently happens
> at module scope, where locals().__setitem__ affects variable lookup,
> and variable mutation affects locals().__getitem__. This can produce
> surprising results if you pa
23 matches
Mail list logo
