Relative-importing *

[rbygscrsepda]

Hi, I'm a newbie at Python. :) Right now it's not letting me import *
from any relative package name--i.e., a name that starts with a dot.
For instance, none of the following work:

from . import *
from .sibiling import *
from .. import *
from ..parent_sibling import *

....and so on. The same error occurs:
SyntaxError: 'import *' not allowed with 'from .'

(I have Python 2.5.1.)

Why would it not let me import * from a relative module at all? I read
that they're planning to make absolute imports the default, so I'd
think that this sort of thing would become more common in the future.

Thanks in advance! :)

[Alex Popescu]

Ben Finney <bi****************@benfinney.id.auwrote in
news:87************@benfinney.id.au:

rb**********@gmail.com writes:

> from . import *
from .sibiling import *
from .. import *
from ..parent_sibling import *

...and so on. The same error occurs:
SyntaxError: 'import *' not allowed with 'from .'

Interesting. I know that 'from foo import *' is frowned on and is
generally worse than importing names explicitly, but I wasn't aware
that it was officialy deprecated. The PEP introducing absolute and
relative imports <URL:http://www.python.org/dev/peps/pep-0328/>
doesn't mention it, except as a friendly "import * is *not* an option
:-)" aside.

Well, I may be looking it from the wrong perspective but what is the
meaning of :

from . import *
from .. import **

Import all modules available at that relative path?

I am not sure why the other 2 versions are not working, though.

../alex
--
..w( the_mindstorm )p.

[Paul Rubin]

Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:

I read "from module import *" as explicitly saying "clobber the current
namespace with whatever names module exports". That's what from does: it
imports names into the current namespace. It isn't some sort of easy to
miss side-effect. If a name already existed, it gets clobbered, just like
any other import:

Seems to me that there should be a compiler warning when this happens.

[Ben Finney]

Paul Rubin <http://ph****@NOSPAM.invalidwrites:

Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:

I read "from module import *" as explicitly saying "clobber the
current namespace with whatever names module exports". That's what
from does: it imports names into the current namespace. It isn't
some sort of easy to miss side-effect. If a name already existed,
it gets clobbered, just like any other import:

Seems to me that there should be a compiler warning when this
happens.

The import happens at run-time. The compiler can't catch it.

--
\ "I stayed up all night playing poker with tarot cards. I got a |
`\ full house and four people died." -- Steven Wright |
_o__) |
Ben Finney

[Bruno Desthuilliers]

Steven D'Aprano a écrit :
(snip)

I do take your point that importing * has the potential to unexpectedly
clobber names you didn't intend,

Another problem is that it makes harder to know from which module a name
comes from.

and that's a good reason to avoid it
unless you have a good reason to use it. But there are good reasons.

The "from module import *" statement is very useful if you wish to export
all the public objects from a "private" module, e.g. emulate what the os
module does with platform specific functions.

Indeed.

(snip)

I certainly agree that "from module import *" is easily abused, but to go
from there to the conclusion that it is a blight that must be stamped out
is far too strong.

As with any "you shall not..." programming rule (goto's, multiple return
points, public attributes, etc, etc), it stands as long as you don't
fully understand when and why it's ok to do it.

[Bruno Desthuilliers]

Paul Rubin a écrit :

Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrites:

>>I read "from module import *" as explicitly saying "clobber the current
namespace with whatever names module exports". That's what from does: it
imports names into the current namespace. It isn't some sort of easy to
miss side-effect. If a name already existed, it gets clobbered, just like
any other import:

Seems to me that there should be a compiler warning when this happens.

if some_runtime_condition:
from foo import *

Paul, I do know why you think compile-time checks are a good thing, but
you do have to understand that Python is *highly* dynamic. Except for
syntax errors, don't expect much help from the Python's compiler.

[Ben Finney]

rb**********@gmail.com writes:

Yes, I'm importing * for a reason, a good one, I think.

Reading your description, I must say I don't see a good reason.

I have a set of modules (the number planned to reach about 400) that
would be dynamically loaded by my program as needed, and they're
somewhat similar to each other. I wish each of them to import * from
a certain "parent" module, so that they'll receive whatever
functions and variables I want all of them to share (using the
parent module's __all__), which may be overrided by the "child"
modules at their discretion. Sort of like class inheritance, but I'm
not doing that because implementing that would be a lot more tedious
and less elegant.

It seems to me, based only on this description, that class inheritance
would be far *more* elegant, and much easier to follow when reading
the code.

If all these functions and other objects are so closely-related that
they form the core of some inheritance-like system, what's so
inelegant about wrapping them in a class so that the inheritance is
explicit in the module where it happens?

--
\ "The only tyrant I accept in this world is the still voice |
`\ within." -- Mahatma Gandhi |
_o__) |
Ben Finney

[Ben Finney]

rb*******@gmail.com writes:

(In addition, it probably would make the program somewhat slower to
have an internal class inside every module, and performance is
important to me, as I'm planning to use this project in a future
game.

This is known as "premature optimisation", and it's harmful. It's
folly to avoid a core part of the language because you're worried
about hypothetical performance issues.

Instead, write your program so that it's easy to understand and
maintain; then, if it's noticeably slow, *measure* the performance
using profiling so you know exactly what is slow; then, and only then,
work on speeding up the slow parts.

These modules are not going to have full-fledged object construction
and so forth. I don't want to construct and use objects at all

If that's truly what you desire, you're using the wrong
language. Everything in Python is an object, even if you don't use
object-oriented programming.

it seems like a waste of time and memory to me to inherit __new__,
__del__, and so on.

You've stated that you're a beginner to programming, so you probably
are unaware that this statement has no basis in how class inheritance
actually works. The point is that inherited behaviour is implemented
in *one* place, not that it's repeated everywhere.

Moreover, this is a further expression of your tendency for premature
optimisation. You should aim instead to write code naturally (learning
what's natural when you're a beginner), and only once you have
something that *works* should you think about performance issues.

All that I want these modules to do is to encapsulate varying
information and behavior for /other/ objects to use.)

This sounds like an ideal case for seeting up a class hierarchy for
this move behaviour.

But regardless of if it's the "right thing to do", do you all think
it's an unintended bug?

Do we think what is an unintended bug?

I think if you go out of your way to avoid the class inheritance
system for implementing what looks strongly like a hierarchy of
behaviour, you will have design bugs. Hopefully now that you're
reading this thread, they won't be *unintended* bugs; whether you
*intentionally* proceed with a buggy design is up to you :-)

--
\ "With Lisp or Forth, a master programmer has unlimited power |
`\ and expressiveness. With Python, even a regular guy can reach |
_o__) for the stars." -- Raymond Hettinger |
Ben Finney

[Marc 'BlackJack' Rintsch]

On Tue, 07 Aug 2007 02:45:23 +0000, rbygscrsepda wrote:

Specifically, in Python 1.5, all of the following generate the error
below:

In Python *1.5*!? I somehow doubt that. ;-)

from . import *
from .sibiling_package import *
from .. import *
from ..cousin_package import *

SyntaxError: 'import *' not allowed with 'from .'

Importing * is a feature, but this seems like an artificial
inconsistency to me. It's as if the compiler raises an error when it
tries to import * as soon as it sees "from .", regardless of what
comes after it. So is this a bug in python? And if it happens to be a
bug, how can I alert the developers of the python compiler?

I'm just guessing here but as * imports are considered bad style the
developers might took the opportunity to forbid them in relative imports
because relative imports are new and this doesn't break old programs.

Ciao,
Marc 'BlackJack' Rintsch

[Steve Holden]

Marc 'BlackJack' Rintsch wrote:

On Tue, 07 Aug 2007 02:45:23 +0000, rbygscrsepda wrote:

>Specifically, in Python 1.5, all of the following generate the error
below:

In Python *1.5*!? I somehow doubt that. ;-)

> from . import *
from .sibiling_package import *
from .. import *
from ..cousin_package import *

SyntaxError: 'import *' not allowed with 'from .'

Importing * is a feature, but this seems like an artificial
inconsistency to me. It's as if the compiler raises an error when it
tries to import * as soon as it sees "from .", regardless of what
comes after it. So is this a bug in python? And if it happens to be a
bug, how can I alert the developers of the python compiler?

I'm just guessing here but as * imports are considered bad style the
developers might took the opportunity to forbid them in relative imports
because relative imports are new and this doesn't break old programs.

Yup, I searched around to find a specific statement of the reason but
couldn't find anything definite. Of course, if you are writing a set of
plugins then wildcard imports would seem like a train wreck waiting to
happen in terms of the discipline required to avoid name collisions.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------