«

Hi,

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".

Thanks,

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

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

> D type system has several big holes,

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

Bye,
bearophile

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!

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).

--
Skip Montanaro - - http://smontanaro.dyndns.org/

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

Márcio Faustino schrieb:
> 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