Hello everybody,
I came upon this behaviour in the current 0.70-beta which surprised me a bit:
julia> f=open("basin.txt","r")
IOStream(<file basin.txt>)
julia> close(f)
julia> for i=1:1
f=open("basin.txt","r")
close(f)
end
┌ Warning: Deprecated syntax `implicit assignment to global variable `f``.
│ Use `global f` instead.
└ @ nothing none:0
julia> typeof(f)
IOStream
Is this just that the depreciation warning is triggered by accident (if was some “normal” variable it would of course be correct) or should I really use global or rename throw-away variables in 1.0 ? Or asking the more basic question: Is there a better way to introduce throw-away temporary variables ?
Also, I would have expected that f is no longer in existence (garbage collected ?) after closing.
Most file IO probably happens in functions and not in main scope, so this is probably quite some niche case.
Best Regards
Christof
It’s unrelated to file operation.
No, depending on what you meant by correct. The warning will still be there.
You are using global variable. The warning is just telling you that you won’t be using global variable implicitly anymore.
You are not using local variable. In 1.0 you will though.
No, closing has nothing to do with GC. And it’s also the other way around. The object will be gc’d after it doesn’t exist.
Hello,
It’s unrelated to file operation.
I am perfectly aware of that.
No, depending on what you meant by correct. The warning will still be there.
With “correct” I referred to the case of a (supposedly performance critical) say Float64 variable where this warning makes obvious sense. What surprised me was that I get this for a variable of type IOStream which is usually not performance critical.
Or would this still trip the compilers optimizer regarding everything else in the loop ?
You are not using local variable. In 1.0 you will though.
OK, I see now that I might use the local keyword. Did not think of searching for the opposite of global.
Best Regards
Christof
Would you expect scoping behavior of variables to be different depending on what kind of object the variable refers to? I’m not sure that’s even possible and would definitely be… weird.
Hello,
certainly different scoping behaviour based on type would be most dangerous. I agree.
I think my surprise boils down to the (obviously wrong) assumption that the variable “f” was gone after the close(f). It is no longer needed after close(f) and ad hoc I would assume it could no longer be used for anything else without completely overwriting the data structure it represents ?
If it would indeed no longer exist than re-using f again inside the loop should be harmless (there would be no longer a f in global scope, right ?) and therefore the depreciation warning would make no sense.
So, at which point would a variable vanish after the close(f) ? I do not yet understand why f is kept around after the close(f), I guess.
Thank you all for your replies !
Best Regards
Christof
close is just a function, it can’t do anything about the binding of the variable f, all it can do is modify the object referred to by f—it continues to be a file handle but after the close(f) call, it’s a closed file handle instead of an open one.
Hello,
right ! For me conceptually f was somehow identical with the “accesability” of the file and ceased to exist together with the file access.
Thank you all !
Best Regards
Christof