This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pje
Recipients barry, brett.cannon, eric.snow, kristjan.jonsson, methane, pconnell, pje
Date 2013-04-05.17:31:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CALeMXf5ozFEFugJrLcxtvmv1M34oeh3nQ73cvXLfSH_ypzufFw@mail.gmail.com>
In-reply-to <CALeMXf5_Z=h_oNRAKsvuoF_Zbes8n1YYDFZdEPyDGXwMTEggxA@mail.gmail.com>
Content
Actually, after a little reflection, I can see that there are more
complex conditions to analyze, if 'b' doesn't import 'b.util', but
some other module imports b and sets b.util.  But that's just freaking
insane and whoever does that probably deserves whatever they get,
especially since a later 'import b.util' would blow away the modified
attribute.

So, this note is just to satisfy myself that the change doesn't
introduce any *new* weirdness unless you are in a case where the
parent imports and replaces the child, and the child is involved in an
import cycle.  If the parent doesn't import the child but just assigns
an attribute, it's already broken the minute somebody else imports the
child, and the same thing applies if something else sets the attribute
without importing the child first, and if it imports the child first,
then the previous analysis (mostly) applies, but either way that code
is broken and will have plenty of other ordering dependencies to debug
on its own.  ;-)

(No wonder Nick said nobody wanted to touch this...  the analysis
alone is a killer.  ;-)   Luckily, it seems we're good to go unless
somebody can find a case I missed.)
History
Date User Action Args
2013-04-05 17:31:19pjesetrecipients: + pje, barry, brett.cannon, kristjan.jonsson, methane, eric.snow, pconnell
2013-04-05 17:31:18pjelinkissue17636 messages
2013-04-05 17:31:18pjecreate