fansipans posted:

Ugh... why is this page taking forever to load?!?!?


Click here for the full 800x587 image.

oh ..... dammit.

Janin posted:

Here's one for you Python programmers out there:

code:

snip

Habnabit posted:

But except: pass makes me want to strangle people.

Zombywuf posted:

Sometimes you don't or can't care if an operation fails.

code:

try:
  log_error(error)
except:
  pass

Habnabit posted:

Sure, let's go ahead and swallow SystemExit, MemoryError, and KeyboardInterrupt.

Zombywuf posted:

Yes, yes, and holy gently caress python makes Ctrl-C an exception. Sheesh. But fair enough, go ahead and catch KeyboardInterrupt, pass the rest.

Scaevolus posted:

But it makes sense to handle trapped signals as exceptions-- would you rather there was a different language construct specifically for those sorts of interrupts?

Zombywuf posted:

Sometimes you don't or can't care if an operation fails.

code:

try:
  log_error(error)
except:
  pass

tef posted:

If you do this in our codebase I will nail your hands to the toilet.

If you don't care if it fails, you should be explicit in the failures to ignore.

tef posted:

And signals are part of posix, not C last time I checked.

Habnabit posted:

I'm not sure if the programmer was concerned that the return statement might raise an exception, or if it was supposed to be a really, really hacky way to either make sure that 'name' was not a unicode string or that the user's LANG environment variable was set correctly.

Janin posted:

I think it's a way to check that "name" is defined, since it's assigned to within the loop.

Zombywuf posted:

It explicitly ignores everything. If you want to ignore everything, this is the mechanism for you.

Zombywuf posted:

Registered interrupt handlers? If the handler decides to exit the regular exit handlers can kick in. This is pretty much a solved problem in C, why Python does it this way is a mystery, and replaces the notion of "function X raised an exception" with "function X or something else raised an exception". You now have to disambiguate the cases.

zootm posted:

I think a lot of languages do it that way, actually. Certainly Ruby does as well. Doesn't seem like something that scales well to multiple threads (insert Ruby gag here) but it certainly seems pretty consistent with the way the language works, especially given that Exceptions are the best way to break normal control flow in exceptional cases.

Stoatbringer posted:

Anyway, every method was labelled numerically, like func1(), func2(), func3() and so on, and he created variable names alphabetically - a, b, c .. z, then onto aa, ab, ac, ad .. az etc.

It took me weeks to work out what the hell anything was doing. Oh, and the total lack of any comments or documentation was great too.

Habnabit posted:

My whole point is you never, ever want to ignore everything. Again, what if a MemoryError is raised? You really want to ignore when there's no memory available, when something higher up the stack could free some memory?

quote:

When a signal comes in, python interrupts the currently executing stack frame and pushes a new stack frame with the python signal handler function. This function is passed the interrupted stack frame as well. If you have a better idea of how to do this in an interpreted language, I'd love to hear it.

Janin posted:

Here's another method, from the same application as before:

code:

snip

Zombywuf posted:

When I don't care if the function is successful, i.e it would be nice to log the error, but we shouldn't tear down the whole program just because we can't. However it turns out you should tear down on memory error because python doesn't guarantee a consistent heap after an out of memory error. I feel dirty just knowing about that.

Zombywuf posted:

I wouldn't let exceptions escape signal handlers. I certainly wouldn't define keyboard interrupt as an exception. Especially not in a language famed for its simplicity and consistency of behavior.

Zombywuf posted:

Then again it uses exceptions to signal generator exits, urgh....

Zombywuf posted:

I wouldn't let exceptions escape signal handlers.

Zombywuf posted:

I certainly wouldn't define keyboard interrupt as an exception.

Habnabit posted:

However, a C extension or python itself can deal with it.

quote:

I don't think you understand how exceptions work. The exception is not the error; the exception is a signal of an error condition. Discarding the exception does not make the error itself go away. If you can't deal with the error condition, don't pretend you can.

quote:

I have no idea what "escape signal handlers" means here. And, again, I urge you to explain how this could be dealt with in a cleaner way.

quote:

Same thing here. How else would you do this? Python is not php; these things have been thought out carefully, and this was found to be the optimal solution. You seem to think these things were slapped together without any forethought, but you also don't seem to have any suggestions on how it could be better implemented.

zootm posted:

Why not? It creates the correct behaviour in the default case in a transparent and understandable way. And if you have some special handler, you can override the default behaviour simply. Sounds like the best of both worlds.

Zombywuf posted:

Deal with what exactly?

Zombywuf posted:

A signal, i.e. some message received from outside your program, should be understood to be happening in a parallel context, not just lumped at the top of stack on top of whatever is currently executing.

Zombywuf posted:

What? Because someone else thought this was the best solution I have to agree?

All hail Hypnoguido, gently caress that.

One simple solution is that of giving generators an iterator interface, i.e. while (mygen.has_more()) { do_stuff(mygen.get_next()); }. This has been implemented in other languages that provide generators or generator like objects - W3C Xpath interface, istream_iterator in C++ and GNU Prolog's C interface to name a few. I'm sure these were thought about and not just slapped together.

Zombywuf posted:

It only provides expected behavior in the case where you're trying to catch KeyboardInterrupt. When you're expecting the semantics of exceptions to mean "something has gone wrong with the code in my try block", the behavior will break your program. How would you recommend a python program include special handlers for SIG_STOP or SIG_KILL (insert non POSIX equivalents at your own leisure)?

Zombywuf posted:

It only provides expected behavior in the case where you're trying to catch KeyboardInterrupt. When you're expecting the semantics of exceptions to mean "something has gone wrong with the code in my try block", the behavior will break your program.

Zombywuf posted:

What? Because someone else thought this was the best solution I have to agree?

All hail Hypnoguido, gently caress that.

Janin posted:

"Out of memory" conditions.

Python docs posted:

exception MemoryError
Raised when an operation runs out of memory but the situation may still be rescued (by deleting some objects). The associated value is a string indicating what kind of (internal) operation ran out of memory. Note that because of the underlying memory management architecture (C's malloc() function), the interpreter may not always be able to completely recover from this situation; it nevertheless raises an exception so that a stack traceback can be printed, in case a run-away program was the cause.

quote:

That would make Python signal handlers pretty useless, since they wouldn't be able to manipulate the execution state except through global C variables.

quote:

What would get_next() do when there's no more data to be retrieved, if not raise an exception? In a case like this:

code:

while (mygen.has_more()) { do_stuff(mygen.get_next()); }
mygen.get_next();

Charles Babbage posted:

On two occasions I have been asked, – "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

quote:

e: Also, it's impossible to implement has_more() for a function-based generator.

quote:

To handle other signals, the programmer just needs to install a signal handler. That handler can do whatever it wants, including raising an exception.

Habnabit posted:

No, I never said that. You seem to be so adamant that this not the best way to do it, without considering that there might be a reason why it is that way or providing an alternate implementation.

quote:

For something like using SIGHUP to reload config files, you can take advantage of the suspended state of the program and update the configuration from within the signal handler. Of course, you'd have to write your code in a way to prevent reloading from a signal handler from interfering with things while you're in the middle of getting information from the configuration, but you'd have to do the same in C anyway. You could even just set a flag that the main loop would acknowledge, or post an event, or something.

quote:

I don't like python.

quote:

I do not like it because it does things differently from what I am used to. This comes down to the simple fact that python is not c++ or c, although sometimes the fact that python is not perl annoys me too.

tef posted:

Zombywuf posted:

Why not just throw a hangup exception and have the controlling code catch it and reload the config? That way the code using the config won't be running when you do the reload.

Zombywuf posted:

From the docs:


So no, python itself is not guaranteed to be able to recover from a memory error and you can only tear down and dump a stack trace if you want to be safe.

Zombywuf posted:

That's a hell of a lot better than injecting exceptions arbitrarily. It means a bit of code that has specific handlers for different exceptions might be seeing exceptions it has no idea how to recover from because they can be thrown anything.

Zombywuf posted:

If the user of function does something with it they're not supposed to then the function should throw.

Zombywuf posted:

No it isn't. Unless you have some crazy ideas about order of evaluation.

Janin posted:

code:

import random
import sys

def gen_func ():
	while True:
		var = random.randint (0, 2)
		if var == 0:
			sys.exit ()
		yield var
		
gen = gen_func ()
gen.has_next () # How could this **ever** be implemented?

Janin posted:

If it's going to throw an exception anyway, why even use has_next()?

code:

import random
import sys

def gen_func ():
	while True:
		var = random.randint (0, 2)
		if var == 0:
			sys.exit ()
		yield var
		
gen = gen_func ()
gen.has_next () # How could this **ever** be implemented?

JoeNotCharles posted:

has_next runs one more iteration of the loop and caches the result. next returns the cached result.

Won't work if the result is dependent on the exact time it's generated, though.

EDIT: didn't even notice the sys.exit, I thought it was just breaking on a random int which couldn't be predicted in advance. Still, if you make it explicit that generators may do their work in the has_next step rather than when calling next, that's code is just defined to be correct!

Munkeymon posted:

That's a lot like saying 'If the program is going to exit when it crashes, why bother trying to fail gracefully?' If you design your generator to make a mess then it will make a mess. Congratulations on restating the garbage in garbage out principal again.

Munkeymon posted:

It just doesn't make a lot of sense to use what most people would consider/assume to be specialized error handling machinery for flow of control or event notification. Not that you can't, but don't expect the rest of the world to agree that it's a perfect system and a great idea.

necrobobsledder posted:

I was working with this one person that would make research report results in an HTML file in Netscape Composer. I saw her load up the stuff in the browser and was wondering why it was taking about 20 seconds to load on a really beefy UltraSPARC workstation. Eventually she sent me the actual report for me to look at and what I saw was that. I wrote a Perl script to filter out those nbsp elements and the file shrunk from about 15 MB to about 100KB. She has a PhD in electrical engineering and is an IEEE fellow. The worst part is that she's supposed to know Perl pretty well since that's what half her experiments were in and know a bit about HTML. Ugh....

Janin posted:

If generators do their work in has_next(), then what should happen when they raise an exception? Does it appear from the has_next() call? That's awfully awkward.

Janin posted:

The generator is not "making a mess". Many generators have side effects, and it's important that the side effects happen at the prescribed time. I inserted the sys.exit() to prevent arguments about pre-caching results; often, the results themselves are unimportant and it's the side-effects of the generator that matter.

quote:

The issue with using a has_next()/get_next() style is that it's not as general as the current system. Any loop implemented with has/get_next() can be wrapped in a generator, but the converse is not true because the behavior of a generator allows unpredictable results.

quote:

I don't think anybody is arguing that it's perfect, but it's certainly better than the alternatives. People just need to get over the "all exceptions are errors" mentality.

Munkeymon posted:

I would say that exiting any serious program from (essentially) inside a loop conditional is making a mess. That's getting into serious WTF territory unless you're just doing it to screw with someone.

Munkeymon posted:

Then maybe it should be called an event, rather than an exception(al circumstance)? We could just call all numbers ints, since we're rewriting common paradigms. Some ints will just happen to have decimals.