On Thu, 9 Apr 2020 20:56:56 -0700
"Gregory P. Smith" wrote:
> On Wed, Apr 8, 2020, 10:37 AM Antoine Pitrou wrote:
>
> > On Wed, 8 Apr 2020 10:18:47 -0700
> > Guido van Rossum wrote:
> > >
> > > > But when I leave "large" temp objects hanging and
> > > > give a rip, I already stick in
On Wed, Apr 8, 2020, 10:37 AM Antoine Pitrou wrote:
> On Wed, 8 Apr 2020 10:18:47 -0700
> Guido van Rossum wrote:
> >
> > > But when I leave "large" temp objects hanging and
> > > give a rip, I already stick in "del" statements anyway. Very rarely,
> > > but it happens.
> > >
> >
> > I recall
On Apr 9, 2020, at 15:13, Wes Turner wrote:
>
> - > And then take a look at how @ApacheArrow
> "supports zero-copy reads for lightning-fast data access without
> serialization overhead."
> - .@blazingsql … #cuDF … @ApacheArrow
> https://docs.blazingdb.com/docs/blazingsql
This isn’t
Thanks for removing the mystery.
FWIW, here are some of the docs and resources for memory management in
Python;
I share these not to be obnoxious or to atoen, but to point to the docs
that would need updating to explain what is going on if this is not
explicit.
-
On Apr 8, 2020, at 23:53, Wes Turner wrote:
>
> Could something just heuristically add del statements with an AST
> transformation that we could review with source control before committing?
>
> When the gc pause occurs is something I don't fully understand. For example:
Your examples don’t
What about nested functions? I am not sure how we can predict if that
variable is going to be used or not.
I think this is a nice idea to have such an analysis, but I don't think is
feasible.
On Thu, 9 Apr 2020 at 04:29, Caleb Donovick
wrote:
> This would almost certainly break my code. As a
Could something just heuristically add del statements with an AST
transformation that we could review with source control before committing?
When the gc pause occurs is something I don't fully understand. For example:
FWIW, this segfaults CPython in 2 lines:
import ctypes
ctypes.cast(1,
This would almost certainly break my code. As a DSL developer I do a lot
of (exec | eval | introspection | ... ) shenanigans, that would make doing
liveness analysis undecidable.
On Wed, Apr 8, 2020 at 10:51 AM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> On Apr 8, 2020,
On Apr 8, 2020, at 09:57, Guido van Rossum wrote:
>
>
> Look at the following code.
>
> def foo(a, b):
> x = a + b
> if not x:
> return None
> sleep(1) # A calculation that does not use x
> return a*b
>
> This code DECREFs x when the frame is exited (at the return
On Wed, Apr 8, 2020 at 10:23 AM Guido van Rossum wrote:
> On Wed, Apr 8, 2020 at 10:05 AM Alex Hall wrote:
>
>> This would break uses of locals(), e.g.
>>
>
> Hm, okay, so suppose the code analysis was good enough to recognize most
> un-obfuscated uses of locals(), exec() and eval() (and
On Wed, Apr 8, 2020 at 10:21 AM Guido van Rossum wrote:
> On Wed, Apr 8, 2020 at 10:05 AM Alex Hall wrote:
>
>> This would break uses of locals(), e.g.
>>
>
> Hm, okay, so suppose the code analysis was good enough to recognize most
> un-obfuscated uses of locals(), exec() and eval() (and
On Wed, 8 Apr 2020 10:18:47 -0700
Guido van Rossum wrote:
>
> > But when I leave "large" temp objects hanging and
> > give a rip, I already stick in "del" statements anyway. Very rarely,
> > but it happens.
> >
>
> I recall that in the development of asyncio there were a few places where
>
On Wed, Apr 8, 2020 at 10:13 AM Tim Peters wrote:
> My guess: it would overwhelmingly free tiny objects, giving a
> literally unmeasurable (just theoretically provable) memory savings,
> at the cost of adding extra trips around the eval loop. So not really
> attractive to me.
Yeah, the extra
On 2020-04-08 17:53, Guido van Rossum wrote:
Look at the following code.
def foo(a, b):
x = a + b
if not x:
return None
sleep(1) # A calculation that does not use x
return a*b
This code DECREFs x when the frame is exited (at the return statement).
But (assuming)
On Wed, Apr 8, 2020 at 10:05 AM Alex Hall wrote:
> This would break uses of locals(), e.g.
>
Hm, okay, so suppose the code analysis was good enough to recognize most
un-obfuscated uses of locals(), exec() and eval() (and presumably
sys._getframe() -- IIUC there's already a Python implementation
On Wed, 8 Apr 2020 09:53:41 -0700
Guido van Rossum wrote:
> Look at the following code.
>
> def foo(a, b):
> x = a + b
> if not x:
> return None
> sleep(1) # A calculation that does not use x
> return a*b
>
> This code DECREFs x when the frame is exited (at the return
[Guido]
> Look at the following code.
>
> def foo(a, b):
> x = a + b
> if not x:
> return None
> sleep(1) # A calculation that does not use x
> return a*b
>
> This code DECREFs x when the frame is exited (at the return statement).
> But (assuming) we can clearly see that x
This would break uses of locals(), e.g.
def foo(a, b):
x = a + b
if not x:
return None
del x
print('{x}, {a}, {b}'.format(**locals()))
return a * b
foo(1, 2)
Plus if the calculation raises an exception and I'm looking at the report
on Sentry, I'd like to see the
> Can anyone tear this idea apart?
`exec` and `eval` come to mind... I'm sure there are also nasty `inspect` hacks
this could break, too?
def foo(a, b):
x = a + b
if not x:
return None
sleep(1) # A calculation that does not use x
return eval("x")
19 matches
Mail list logo
