Earlier quoted context omitted.
An entomology etymology ontology difficulty-novelty hierarchy?
Bravo!
First fan is best fan.
Bug #915: Solved
101–110 of 111 posts
Re: Bug #915: Solved
#102Earlier quoted context omitted.
My question is: what is your alternative to exceptions, and how would they would have made the error easier to spot? Its not obvious that the error would have been easier to spot if it had been written using Go's `!= nil` pattern or Rust's `?` pattern. My experience is that while its true that its easy to have bugs in implicit exception handling logic, its just as easy, maybe easier, to have bugs in the explicit boil…
> how would they would have made the error easier to spot? There was a try block with two function calls, and it seems like the author assumed only the first function call could throw. With return-based errors, the error handling wouldn't implicitly be shared between the two functions. The author would write the handling for the first function, and then they would notice the second function could return an error stat…
What makes you think that "the author assumed only the first function call could throw?"
Programmers in exception languages never think (or at least should never think) "X cannot throw" because it is never true. Any function has the potential of throwing an exception. This is even more true in Python than in other exception throwing languages.
No, the problem here is that the author has realized that they need special cleanup logic in the case that a file fails to be opened, but they applied that logic too broadly.
Re: Bug #915: Solved
#103Earlier quoted context omitted.
> how would they would have made the error easier to spot? There was a try block with two function calls, and it seems like the author assumed only the first function call could throw. With return-based errors, the error handling wouldn't implicitly be shared between the two functions. The author would write the handling for the first function, and then they would notice the second function could return an error stat…
What makes you think that "the author assumed only the first function call could throw?" Programmers in exception languages never think (or at least should never think) "X cannot throw" because it is never true. Any function has the potential of throwing an exception. This is even more true in Python than in other exception throwing languages. No, the problem here is that the author has realized that they need specia…
[deleted]
Re: Bug #915: Solved
#104Earlier quoted context omitted.
> how would they would have made the error easier to spot? There was a try block with two function calls, and it seems like the author assumed only the first function call could throw. With return-based errors, the error handling wouldn't implicitly be shared between the two functions. The author would write the handling for the first function, and then they would notice the second function could return an error stat…
What makes you think that "the author assumed only the first function call could throw?" Programmers in exception languages never think (or at least should never think) "X cannot throw" because it is never true. Any function has the potential of throwing an exception. This is even more true in Python than in other exception throwing languages. No, the problem here is that the author has realized that they need specia…
So for reference the second line is:
return _TemporaryFileWrapper(file, name, delete)
Because it's almost true, and the code cleanup is clearly designed around just the first function.
_TemporaryFileWrapper does nothing in its __init__ except copy the four parameters into the object. There's no reason to anticipate a problem.
But thinking about it more precisely, there's an even worse issue.
Even if neither function has an error, if you get a KeyboardInterrupt between the object creation and the actual return, everything gets corrupted.
People aware of the bug, trying to fix this code, suggested a nested try/catch, and I think that would still explode if the timing was exactly wrong.
Because really, who thinks about a return statement throwing? It's an unintuitive problem that can only happen with this style of exceptions.
It's probably even worse than that. If an exception can hit right after the file object is made then you get a similar problem...
Is there anything in Python that restricts the timing of KeyboardException or is this entire adventure on extremely treacherous territory?
Re: Bug #915: Solved
#105Earlier quoted context omitted.
> It’s neither type-safe nor unambiguous. How'd you get here? It's exactly as type-safe as the unwrapped hash table, which is admittedly not especially type-safe, and it's fully unambiguous.
> It's exactly as type-safe as the unwrapped hash table, which is admittedly not especially type-safe Yes. > and it's fully unambiguous. No, you have any random value flagged as not present (in fact you can forget about or ignore the flag entirely), and no clue if that means anything.
Can you provide an example of what you mean by "ambiguity"?
Re: Bug #915: Solved
#106Earlier quoted context omitted.
What makes you think that "the author assumed only the first function call could throw?" Programmers in exception languages never think (or at least should never think) "X cannot throw" because it is never true. Any function has the potential of throwing an exception. This is even more true in Python than in other exception throwing languages. No, the problem here is that the author has realized that they need specia…
So for reference the second line is: return _TemporaryFileWrapper(file, name, delete) > What makes you think that "the author assumed only the first function call could throw?" Because it's almost true, and the code cleanup is clearly designed around just the first function. _TemporaryFileWrapper does nothing in its __init__ except copy the four parameters into the object. There's no reason to anticipate a problem. B…
That's precisely the point I was making: there is no python code which is guaranteed not to throw. If the original author thought that the line of code in question wouldn't throw, they were were wrong and fundamentally misunderstood Python.
Re: Bug #915: Solved
#107Earlier quoted context omitted.
So for reference the second line is: return _TemporaryFileWrapper(file, name, delete) > What makes you think that "the author assumed only the first function call could throw?" Because it's almost true, and the code cleanup is clearly designed around just the first function. _TemporaryFileWrapper does nothing in its __init__ except copy the four parameters into the object. There's no reason to anticipate a problem. B…
That's precisely the point I was making: there is no python code which is guaranteed not to throw. If the original author thought that the line of code in question wouldn't throw, they were were wrong and fundamentally misunderstood Python.
Well the code wouldn't have caused any errors if it only caught normal exceptions, at least.
> That's precisely the point I was making: there is no python code which is guaranteed not to throw.
Well the first thing you said is "what is your alternative to exceptions, and how would they would have made the error easier to spot? Its not obvious that the error would have been easier to spot if it had been written using Go's `!= nil` pattern or Rust's `?` pattern."
In those languages, you can't have an error state trigger between lines of code, or inside a line of code that does basic things like assigning to a local variable or returning.
It won't happen in C++ either (with certain assumptions).
Python is a language that's supposed to be straightforward, and very few coders are going to understand exactly how hostile exceptions can be. So while these assumptions shouldn't have been made, the blame goes toward the design of the language. An alternative system would be better.
Re: Bug #915: Solved
#108Earlier quoted context omitted.
That's precisely the point I was making: there is no python code which is guaranteed not to throw. If the original author thought that the line of code in question wouldn't throw, they were were wrong and fundamentally misunderstood Python.
Well the code wouldn't have caused any errors if it only caught normal exceptions, at least. > That's precisely the point I was making: there is no python code which is guaranteed not to throw. Well the first thing you said is "what is your alternative to exceptions, and how would they would have made the error easier to spot? Its not obvious that the error would have been easier to spot if it had been written using…
> Well the code wouldn't have caused any errors if it only caught normal exceptions, at least.
Uhh... it was a normal exception that triggered the bug in question.
> Well the first thing you said is
Yes, that's the first thing I said. But the point I'm making here is that your initial response to that is probably wrong: "the author assumed only the first function call could throw" That's just not how you think in Python. (Or at least it is not how you should think.)
My point is this: the bug wasn't assuming that the second function wouldn't fail. The bug was assuming that the same cleanup code was appropriate in the case of either failure. That same bug could easily exist with return codes as it does in exceptions.
> Python is a language that's supposed to be straightforward
In fairness to Python, this is an atypical case. The problem arises because this is low level code dealing directly with fds. Most of the time, code will deal with higher level objects which will properly clean up after themselves regardless of what crazy stuff you do with them.
Re: Bug #915: Solved
#109Earlier quoted context omitted.
Well the code wouldn't have caused any errors if it only caught normal exceptions, at least. > That's precisely the point I was making: there is no python code which is guaranteed not to throw. Well the first thing you said is "what is your alternative to exceptions, and how would they would have made the error easier to spot? Its not obvious that the error would have been easier to spot if it had been written using…
> Well the code wouldn't have caused any errors if it only caught normal exceptions, at least. Uhh... it was a normal exception that triggered the bug in question. > Well the first thing you said is Yes, that's the first thing I said. But the point I'm making here is that your initial response to that is probably wrong: "the author assumed only the first function call could throw" That's just not how you think in Pyt…
> Uhh... it was a normal exception that triggered the bug in question.
That doesn't count because it was an invasive monkeypatch that took a function that could not possibly cause an error and made it throw.
> My point is this: the bug wasn't assuming that the second function wouldn't fail. The bug was assuming that the same cleanup code was appropriate in the case of either failure.
Maybe. Hard to know for sure.
> In fairness to Python, this is an atypical case.
I dunno, pretty much any code that uses a catch block to undo things has to be very carefully written. Even if you're wrapping things in higher level objects, you still have ugly scenarios where you're mutating a data structure and have to unwind the changes halfway through. I bet tons of that code is written under the assumption that there will be no exceptions.
I guess if we consider "trying to catch KeyboardInterrupt at any level without immediate exit" as a weird barely-supported case, then things are fine.
Re: Bug #915: Solved
#110Earlier quoted context omitted.
Well one person actually provided a solution, but then one of the maintainers just dismissed it because it was on Github, then locked the issue.
It seemed unclear that the patch addressed all the issues raised in the ticket, and looking at random patches still requires dev time. It is a different story when someone else actively works on getting it upstreamed and working on resolving any issues. It's about who volunteers to do the hard work. Given that no one stepped up to do it yet and random users chimed in with aggressive and/or unhelpful noise, locking th…
Uh, as far as I can see, all the hard work is done, and has been merged into other forks. The Gnome devs just ideologically disagree. The whole ticket is a perfect example of “don’t let perfect be the enemy of good”.