[PATCH] omniORBpy: allow "from <parents> import <module>" after partial module loading

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============90942873917493916==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig8440108050337EC5686D7593"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8440108050337EC5686D7593
Content-Type: multipart/mixed; boundary="------------020706000000040006090300"

This is a multi-part message in MIME format.
--------------020706000000040006090300
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hello everyone,

I assume to have found a minor bug in omniORBpy and hope that this list
is the right place for this kind of mail...

Please, assume the following setup:

 - two IDL files (A1.idl and A2.idl) contribute to the same CORBA
   module A

 - the CORBA module B #includes only e.g. A1.idl

 - omniidl is used with -Wbpackage=3DP or modules A and B are
   sub-modules beneath module P (I only tested the former, not the
   latter case though)

And now, consider the following python code:

    1: import P.B
    2: from P import A

At this point, A only contains the definitions from P/A1_idl.py.
P/A/__init__.py is never called. This is because, after line 1, P
already contains an attribute A, referencing the partial module and
"from ... import ..." in line 2 uses that attribute instead of loading
the actual module. ("import P.A" works -- probably because it doesn't
look at P's attributes.)

As P.A is still a _partial_ module right after line 1, IMHO it shouldn't
be published in P yet.

As far as I can tell, omniORB internally always uses fully qualified
access going through omniORB.openModule() and doesn't depend on the
above mentioned publishing of partial modules. Normal users depending on
this would be buggy as well, as they should be loading the desired
module themselves (and should therefore never be accessing a partial
module directly anyway).

So, in conclusion, my approach is to no longer publish partially loaded
modules in their parent modules (i.e. not add an attribute pointing to
the partially loaded child module to the parent module). AFAICT, this
circumvents all problems and removes no features.

I've attached a patch containing this one-line change to
omniORB.updateModule() and a tar-ball with a Makefile reproducing the
problem.

Cheers, Fabian

--------------020706000000040006090300
Content-Type: text/x-patch;
 name="omniORBpy-fix-updateModule.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="omniORBpy-fix-updateModule.patch"

omniORBpy: allow "from <parents> import <module>" after partial module lo=
ading

--- omniORB/__init__.py	2007-10-04 01:27:50.000000000 +0200
+++ omniORB/__init__.py	2007-10-04 01:27:57.000000000 +0200
@@ -574,7 +574,6 @@
=20
         else:
             newmod =3D imp.new_module(current)
-            if mod: setattr(mod, name, newmod)
             _partialModules[current] =3D mod =3D newmod
=20
         current =3D current + "."

--------------020706000000040006090300
Content-Type: application/x-gzip;
	name="omniORBpy-fix-updateModule_test-case.tar.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
	filename="omniORBpy-fix-updateModule_test-case.tar.gz"

H4sIAJ82BEcAA+2YbU/bMBDH+7b+FAdlAiaSJulDpG68aBjSJsE2DdDGq8pJnNUidaLYgVXT
vvvOSVtgrKOCqdU0/0Sb2nfxnR/+dkg2EfzDpyCfWgn/ZpV5TBU7zeIyZSPFpLIiKlm78Twc
xO/19NX1/X597VflOQ3X8R3X6Th9v9tw3H4X3aH3zLgrUUpFC4BGcvWYHyvkOhJaL9kq8z8c
Uc/mcfrEGHqC+93u0vl3O/P5d12/02loK7qB81d7uoT/fP5bPBExS0BP8ejdmxPSwhIX7LaC
TKrlAEP4TppcKFYkNGJAPfj+4xXBP9JiIuYJtNuwtbhr0/0yrMaq+nfXpX9vpv+u0f86uKN/
91f9u3/Uv7tE/67R/z/ESvoPniH+xuP699y5/r2er/3wKQC3AaP/NTDXf3BP/HWJtLiI0jJm
sD0/AbYX20FwfzsI6+2ANGfmI22+Y49qe/PhlhGY/WKDrKT/U3qF6yJlT4zxmP57vjc//z3f
8RqOhw8CrtH/Ojj+cnx0cT4MTo7P4BDqKU85E+rubyuaxKneF3AMrlkBNIqyUiguvkJRCkt7
SkJQxmeHO3s3PI0jWsTwUm8Y++Tj5fnbD++1yEdn5xeBdsmpkmUoFbzQLgf4ab8Y4bedTw92
9nQ7+/uEEJqmg2ZYYnsWGquESJQyKgbN6qJrCdHVA9LMp2qcCc/ugd3WVdgWIYubB7Cz92si
GOJu5EGdDWlqSeh4Vli3CdbnMKfRFf3KDqt6kcDOa0IWOWD0YgJWkYBujxD7I8a5HADmD5UT
3HbiNvFNz3zNSvqfjedTYzz2/sfv9Ofvf7yu/v/fQwfP6H8dtLbapSzaIRfthYJQF5M8K5Re
znaAhzU++3MJUnFc0BRyWihOU5id9FTEIMdZmcZiV0GoK4AqVfCwVAyyShQwZcomVOIYKhCZ
gjGV2mdPyx92h7uoxaTIJpXvLPhwEVhkNxg2KdN7MUd10NGSkDacj/FeLrEVWqpsQhWPUJFT
yIvsmscshnAKasyg7veurFSqLI5yZWN6zbOyWOT8m3yXWh4a7ABNofvQNsR6qusxyXeJfqdS
dVcBvaY8pWHKDnAIslAnIzH1Gyr1IGMPclZgOc0oduRBllWzHja76dVlMBgMBoPBYDAYDAaD
wWDYND8BztyUZQAoAAA=
--------------020706000000040006090300--

--------------enig8440108050337EC5686D7593
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBDeDARH1aMTipzMRAi+4AJ971dYcNByA2FhrSleIxZkRZ1BwwgCgoySK
lFkWmDcF+oNajllyuibAYfc=
=2RU4
-----END PGP SIGNATURE-----

--------------enig8440108050337EC5686D7593--


--===============90942873917493916==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
omniORB-dev mailing list
[email protected]
http://www.omniorb-support.com/mailman/listinfo/omniorb-dev

--===============90942873917493916==--