On 07/13/2013 02:29 PM, Jim Mooney wrote:
Steven D'Aprano <st...@pearwood.info>
No, actually, it's the opposite of a gotcha. If a module expects to use
truncated division, and *fails* to "from __future__ import division",
that's what it needs to get. If your import would change what the other
module sees, then you could change the behaviour of the other module (and
probably break it) just by importing something from __future__.
====
\
Or worse, break it in a way that wasn't apparent until the plane fell out
of the sky ;')
Actually, I meant the reverse gotcha. Expecting float division when your
imported module stuck to truncated. But either way it's good to know
__future__ is not your usual sort of import.
You still don't understand. If you write a module and I import it, then
other imports BY ME don't affect your module. Whether it's a __future__
one or not. My import affects my global namespace, not yours. My
compile-time switches affect my divide, not yours. Same thing.
*Unless of course, we're in a case of recursive imports, or doing
monkey-patching, or code-generation.
Same thing with the encoding line at the beginning of my module. It
affects how string literals and symbol names are to be decoded in my
module, not in yours. It's perfectly reasonable and safe to have some
source files encoded in utf-8 and some in latin-1. Pain in the neck for
the text editor, but that's why the encoding string is flexible, so that
editors like emacs can honor the same one.
--
DaveA
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
