Alan Bawden wrote:
The Java compiler has no way to know whether a variable references an
object with a finalize() method that has side effects
It should be able to tell in some situations, e.g.
String a = "hello";
String b = a.replace('e', 'u');
There's no way that b can reference
r...@zedat.fu-berlin.de (Stefan Ram) writes:
> Alan Bawden writes:
> >The Java compiler has no way to know whether a variable references an
> >object with a finalize() method that has side effects
>
> java.lang.Object#finalize() is deprecated since Java 9.
And we are advised to use a
On Fri, Mar 1, 2019 at 9:31 AM Marko Rauhamaa wrote:
>
> Roel Schroeven :
> > In the absence of any other mention of bindings being removed, to me
> > it seems clear that bindings are not automatically removed. Otherwise
> > many things become ambiguous. Example: the documentation for dicts
> >
Roel Schroeven :
> In the absence of any other mention of bindings being removed, to me
> it seems clear that bindings are not automatically removed. Otherwise
> many things become ambiguous. Example: the documentation for dicts
> defines "d[key] = value" as "Set d[key] to value". Does that mean
Rhodri James schreef op 28/02/2019 om 13:09:
On 27/02/2019 21:39, Roel Schroeven wrote:
Rhodri James schreef op 27/02/2019 om 15:18:
Aren't we overthinking this?
I think it's pretty clear that a variable is never deleted before it
goes out of scope. A quick search in the documentation points
Chris Angelico :
> What if an exception gets raised at some point before the function has
> returned? The exception object will give full access to the function's
> locals.
It wouldn't hurt for the Python gods to make an explicit ruling on the
matter.
Marko
--
On Thu, Feb 28, 2019 at 11:13 PM Rhodri James wrote:
>
> On 27/02/2019 21:39, Roel Schroeven wrote:
> > Rhodri James schreef op 27/02/2019 om 15:18:
> > Aren't we overthinking this?
> >
> > I think it's pretty clear that a variable is never deleted before it
> > goes out of scope. A quick search
On 27/02/2019 21:39, Roel Schroeven wrote:
Rhodri James schreef op 27/02/2019 om 15:18:
Aren't we overthinking this?
I think it's pretty clear that a variable is never deleted before it
goes out of scope. A quick search in the documentation points me to
Alan Bawden :
> Gregory Ewing writes:
>
>> Alan Bawden wrote:
>> > the Java Language
>> > Specification contains the following language:
>> >Optimizing transformations of a program can be designed that reduce
>> >the number of objects that are reachable to be less than those which
>> >
Gregory Ewing writes:
> Alan Bawden wrote:
> > the Java Language
> > Specification contains the following language:
> >Optimizing transformations of a program can be designed that reduce
> >the number of objects that are reachable to be less than those which
> >would naively be
Thomas Jollans wrote:
If the inspect module's stack frame inspection machinery is supported,
then any function call might access any local... (though I don't think a
compliant Python implementation necessarily has to support the inspect
module fully).
You can be devious even without using the
Alan Bawden wrote:
the Java Language
Specification contains the following language:
Optimizing transformations of a program can be designed that reduce the
number of objects that are reachable to be less than those which would
naively be considered reachable. For example, a Java
On 27/02/2019 22:39, Roel Schroeven wrote:
> Aren't we overthinking this?
No, it's just that nobody had found the evidence you did.
>
> I think it's pretty clear that a variable is never deleted before it
> goes out of scope. A quick search in the documentation points me to
>
Rhodri James schreef op 27/02/2019 om 15:18:
On 27/02/2019 06:56, Marko Rauhamaa wrote:
Alan Bawden :
But I appreciate that that isn't the true question that you wanted to ask!
You are wondering if a Python implementation is _permitted_ to treat the
code you wrote _as if_ you had written:
On 27/02/2019 16.41, Marko Rauhamaa wrote:
> Rhodri James :
>> The description of the with statement does explicitly say that the
>> context manager's __exit__() method won't be called until the suite
>> has been executed, so the reference to the open file must exist for at
>> least that long.
>
Rhodri James :
> On 27/02/2019 06:56, Marko Rauhamaa wrote:
>> Then there's the question of a sufficient way to prevent premature
>> garbage collection:
>>
>> def fun():
>> f = open("lock")
>> flock.flock(f, fcntl.LOCK_EX)
>> do_stuff()
>> f.close()
>>
On 27/02/2019 06:56, Marko Rauhamaa wrote:
Alan Bawden :
But I appreciate that that isn't the true question that you wanted to ask!
You are wondering if a Python implementation is _permitted_ to treat the
code you wrote _as if_ you had written:
def fun():
f = open("lock")
On 27/02/2019 04.14, Alan Bawden wrote:
> Marko Rauhamaa writes:
>> I couldn't find an immediate answer in the documentation.
>
> I suspect that given the history of Python, pretty much everybody has
> always assumed that a Python implementation will not delete local variables
> early. But I
Just to add on regarding file I/O. It would be more pythonic to use.
with open(path):
do_stuff()
On Wed, Feb 27, 2019, 3:31 AM Marko Rauhamaa wrote:
>
> Consider this function:
>
> def fun():
> f = open("lock")
> flock.flock(f, fcntl.LOCK_EX)
> do_stuff()
>
Alan Bawden :
> Marko Rauhamaa writes:
>> def fun():
>> f = open("lock")
>> flock.flock(f, fcntl.LOCK_EX)
>> do_stuff()
>> sys.exit(0)
>>
>> Question: can a compliant Python implementation close f (and,
>> consequently, release the file lock) before/while
Marko Rauhamaa writes:
> def fun():
> f = open("lock")
> flock.flock(f, fcntl.LOCK_EX)
> do_stuff()
> sys.exit(0)
>
> Question: can a compliant Python implementation close f (and,
> consequently, release the file lock) before/while do_stuff() is
> executed?
A
On 2/26/19 3:54 PM, Marko Rauhamaa wrote:
> Consider this function:
>
> def fun():
> f = open("lock")
> flock.flock(f, fcntl.LOCK_EX)
> do_stuff()
> sys.exit(0)
>
> Question: can a compliant Python implementation close f (and,
> consequently, release the file
On Wed, Feb 27, 2019 at 9:00 AM Marko Rauhamaa wrote:
> Consider this function:
>
> def fun():
> f = open("lock")
> flock.flock(f, fcntl.LOCK_EX)
> do_stuff()
> sys.exit(0)
>
> Question: can a compliant Python implementation close f (and,
> consequently,
Consider this function:
def fun():
f = open("lock")
flock.flock(f, fcntl.LOCK_EX)
do_stuff()
sys.exit(0)
Question: can a compliant Python implementation close f (and,
consequently, release the file lock) before/while do_stuff() is
executed?
I couldn't find
24 matches
Mail list logo
