Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not necessarily, but I just found it interesting that it wasn't really anything all that crazy - it could in theory be possible to encounter this in a big enough code base that makes heavy use of coroutines and custom exception types.


It is crazy to have a class constructor return something that isn't an instance of the class. That's nonsense code and is unlikely to occur in a codebase of any size, regardless of how often they define custom exception types.

I wouldn't have bothered filing the bug.


The Python interpreter should not segfault for this.


Yes, of course. But is it worth your time to fix it? Probably not.

If I jump on my bed enough, it'd probably break, but I'm not complaining to the manufacturer about the issue.


to re-analogize with tools :

if I used my Snap-On(tm) wrench as a prybar (incorrect usage) and broke it, Snap-On would still replace it in exchange for the broken tool and knowledge of the situation that broke it.

To pretend that a language bug isn't worth reporting because you and your codebases will never encounter it seems short-sighted. Down the line, years from now, who knows what you'll have to do to get something to work. Maybe it'll be something this silly, and you'll be happy that the folks before you encountered it and remediated it.

All that said, from a practical standpoint I agree with you.

If you're doing something wacky, and it turns out as wacky as you thought it would, you're probably attacking the problem from the wrong angle, anyway. I just want to remind everyone that 'wacky' things are required and implemented daily in codebases around the world -- regardless of how bad they smell.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: