On Mon, Nov 9, 2009 at 4:13 PM, Yuvgoog Greenle <[email protected]> wrote: > First of all I'd like to apologize to Ben, this may sound like a lame > excuse but I guess Ben Finney somehow turned into Benny because of my > lack of sleep. So again sorry for that, I really didn't mean it that > way. > > Yuvgoog is a pseudonym indeed, my real name is Yuval Greenfield. I'd > grown a habit of trying to see where I get spam mail from so I use > names mangled with the service name. You might see me as Yuvpic > Greenasa, Yuvfaceal Greenbookfield, etc. I guess this habit's one I > should get rid of, especially seeing as it really hasn't paid off (I > haven't caught a single spammer yet after probably 6 years of it).
Thanks Yuval. This puts a much more human face on your posts, which matters to me. A lot, actually. > Concerning debugging warnings, I have to say I currently remember my > experience with 2: the deprecation of sets and the deprecation of > string exceptions. On both occasions the warnings helped me figure > things out before my code broke. Specifically with raising string > exceptions, warnings saved me and my colleagues from alot of bad code, > string exceptions were the convention at my office and I only found > out early because I installed a new python that warned me. Finding > this out as an error might not have been too bad either but it would > have probably taken more time until I got a python that doesn't allow > raising strings (2.6!). In the balance, I think it's easy enough to find these things by using the version that actually breaks things. If you are your only customer, until then, there's little benefit in fixing the warnings ahead of time (except perhaps for learning -- but, strangely, there are ways of learning about programming besides trying things out :-). If you have other customers, you should get used to testing with the latest version of Python anyway -- running without warnings in a previous version really isn't a good enough test for future compatibility. -- --Guido van Rossum (python.org/~guido) _______________________________________________ stdlib-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/stdlib-sig
