Public imports

  • Thread starter Márcio Faustino
  • Start date
B

Bruno Desthuilliers

Márcio Faustino a écrit :
Hi,

Does Python support public imports instead of the default private?

Python has no notion of "public" or "private" !-)
Something like D's "public import" (see <http://www.digitalmars.com/d/
2.0/module.html>)

Python imports don't work as D imports (as far as I can tell from the
above link). The Python import statement binds imported name - whether
the module object itself[1] or the explicitely[2] or implicitely[3]
specified names from the module object - into the importing module's
namespace.

[1] import some_module
[2] from some_module import some_name
[3] from some_module import *


IOW, if module_b imports module_a and module_c import module_a, module_a
will be accessible in module_c as module_b.module_a. If module_b import
name_x from module_a and module_c imports module_b, name_x will be
accessible in module_c as module_b.name_x. Etc, etc....

HTH
 
B

bearophileHUGS

Márcio Faustino:
Does Python support public imports instead of the default private?
Something like D's "public import" (see <http://www.digitalmars.com/d/
2.0/module.html>) or even Perl's "export_to_level".

D type system has several big holes, and I am trying to push Walter to
fix some of those, to make it look a little more sane, like for
example the Python module system.
Public imports are often bad.

Bye,
bearophile
 
B

bearophileHUGS

D type system has several big holes,

I meant "D module system", of course. Sorry.

Bye,
bearophile
 
M

Márcio Faustino

So, no chance of doing this:

# "A.py"
from __future__ import division, with_statement

# "B.py"
from A import *
print 1 / 2

....and printing 0.5, right? Too bad :)
Thanks!
 
S

skip

Márcio> So, no chance of doing this:
Márcio> # "A.py"
Márcio> from __future__ import division, with_statement

Márcio> # "B.py"
Márcio> from A import *
Márcio> print 1 / 2

Márcio> ...and printing 0.5, right? Too bad :)

"from __future__ ..." isn't really an import statement in the usual sense of
the term. It affects the byte code compiler immediately and I believe only
when using that syntax. That it actually adds a name to the module's
namespace is not really used (at least, not often).
 
B

Bruno Desthuilliers

Márcio Faustino a écrit :
So, no chance of doing this:

# "A.py"
from __future__ import division, with_statement

# "B.py"
from A import *
print 1 / 2

...and printing 0.5, right?

Nope, but for totally unrelated reasons (cf Skip's anwer).

OTHO, this is valid:

# foo.py
def bar():
return "bar"

# A.py
from foo import bar

# B.py
from A import bar
print bar()


FWIW, this is often used in packages __init__.py to hide the package's
internal organization (or when a module starts to grow too big and has
to be refactored as a package without breaking client code).

HTH
 
D

Diez B. Roggisch

Márcio Faustino said:
So, no chance of doing this:

# "A.py"
from __future__ import division, with_statement

# "B.py"
from A import *
print 1 / 2

...and printing 0.5, right? Too bad :)

Au contraire - *very* good. If it were otherwise, what would happen to
code that _relies_ on / returning an int - some 3rd-party-lib for
example? The same goes for code that contains "with" as variable name or
some such.


Diez
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top