473,396 Members | 2,059 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,396 software developers and data experts.

Simplifying imports?

I like to keep my classes each in a separate file with the same name of
the class. The problem with that is that I end up with multiple imports
in the beginning of each file, like this:

from foo.Bar import Bar
from foo.Blah import Blah
from foo.Zzz import Zzz

What I'd like to do would be to replace it all by a single line:

from foo.* import *

Of course, that doesn't work, but is there a way to do something like
that?

Chapolim

Sep 13 '05 #1
9 1500
ch***************@bol.com.br wrote:
I like to keep my classes each in a separate file with the same name of
the class. The problem with that is that I end up with multiple imports
in the beginning of each file, like this:

from foo.Bar import Bar
from foo.Blah import Blah
from foo.Zzz import Zzz
Must ... resist ... temptation ... to ... complain ... about ... J...
What I'd like to do would be to replace it all by a single line:

from foo.* import *

Of course, that doesn't work, but is there a way to do something like
that?


In foo there is a file __init__.py, right? If you have 3 class files
in foo: bar.py, baz.py, and bax.py, you're __init__.py could contain:

# __init__.py
from foo.bar import Bar
from foo.baz import Baz
from foo.bax import Bax
# end of __init__.py

Then, voila:
import foo
dir(foo)

['Bar', 'Bax', 'Baz', '__builtins__', '__doc__', '__file__',
'__name__', '__path__', 'bar', 'bax', 'baz']

You could write code in __init__.py to import all the files in foo/ if
you wanted. That way you wouldn't have to explicitly list each file.
(Hint: see os.listdir() and __import__().)

HTH,
n

PS. I don't really like this approach. It seems too implicit
(magical).

Sep 13 '05 #2
On Monday 12 September 2005 10:09 pm, ch***************@bol.com.br wrote:
I like to keep my classes each in a separate file with the same name of
the class. The problem with that is that I end up with multiple imports
in the beginning of each file, like this:

from foo.Bar import Bar
from foo.Blah import Blah
from foo.Zzz import Zzz

What I'd like to do would be to replace it all by a single line:

from foo.* import *

Of course, that doesn't work, but is there a way to do something like
that?


Apparently "foo" is already a package defined using __init__.py,
so you know about that part already.

Just change its contents to read:

from Bar import Bar
from Blah import Blah
from Zzz import Zzz

Then whenever you need to use these classes, you only need:

from foo import Bar, Blah, Zzz

or

from foo import *

Cheers,
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com

Sep 13 '05 #3
Terry Hancock wrote:
On Monday 12 September 2005 10:09 pm, ch***************@bol.com.br wrote:
I like to keep my classes each in a separate file with the same name of
the class. The problem with that is that I end up with multiple imports
in the beginning of each file, like this:

from foo.Bar import Bar
from foo.Blah import Blah
from foo.Zzz import Zzz

What I'd like to do would be to replace it all by a single line:

from foo.* import *

Of course, that doesn't work, but is there a way to do something like
that?


Apparently "foo" is already a package defined using __init__.py,
so you know about that part already.

Just change its contents to read:

from Bar import Bar
from Blah import Blah
from Zzz import Zzz

Then whenever you need to use these classes, you only need:

from foo import Bar, Blah, Zzz

or

from foo import *


Or, if the Bar, Blah and Zzz classes are small enough, there's no need to
put each of them in separate modules. Just put them in foo.py.

Concise structuring of classes and modules is not easy. Structure too much,
and you will not see the wood for the trees. Structure too little, and you
won't find things anymore. IMO, the Twisted project is an example of
excellent Python structuring.

Reinhold
Sep 13 '05 #4
ch***************@bol.com.br wrote:
I like to keep my classes each in a separate file with the same name of
the class.


Let me guess: you have a C++ or Java background ?-)

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Sep 13 '05 #5
bruno modulix wrote:
Let me guess: you have a C++ or Java background ?


You're right, I come from Java :). I'm still learning the Pythonic
approach. Thank you guys

Chapolim

Sep 13 '05 #6
"Terry Hancock" <ha*****@anansispaceworks.com> wrote:
On Monday 12 September 2005 10:09 pm, ch***************@bol.com.br wrote:
I like to keep my classes each in a separate file with the same name of
the class. The problem with that is that I end up with multiple imports
in the beginning of each file, like this:

from foo.Bar import Bar
from foo.Blah import Blah
from foo.Zzz import Zzz

What I'd like to do would be to replace it all by a single line:

from foo.* import *

Of course, that doesn't work, but is there a way to do something like
that?


Apparently "foo" is already a package defined using __init__.py,
so you know about that part already.

Just change its contents to read:

from Bar import Bar
from Blah import Blah
from Zzz import Zzz


If you do this often or have lots of classes you want to import this
way, you could automate it:

#======== Foo.py ====================================
class Foo(object):
pass

#======== Bar.py ====================================
class Bar(object):
pass

#======== test.py ====================================
from autoimport import autoimport
autoimport("Foo","Bar")

if __name__ == '__main__':
print Foo
print Bar

# output:
# <class 'Foo.Foo'>
# <class 'Bar.Bar>

#======== autoimport.py ====================================
import sys

def autoimport(*modulenames):
'''
Perform the equivalent of "from XXX import XXX" for every
module XXX in modulenames. In case of packaged modules, it is
equivalent to "from XXX.YYY.ZZZ import ZZZ"
'''
caller_frame = sys._getframe(1)
caller_locals = caller_frame.f_locals
# import every module XXX and add the XXX.XXX object
# to the caller's locals
for name in modulenames:
# in case of packaged modules A.B.C, make sure to import C
module = __import__(name, caller_frame.f_globals,
caller_locals, [name])
# extract 'C' from 'A.B.C'
attribute = name[name.rfind('.')+1:]
if hasattr(module,attribute):
caller_locals[attribute] = getattr(module,attribute)

#================================================= =

Or even better, forget about the braindead java restriction of one
class per file and organize your code as it makes more sense to you.

HTH,
George

Sep 13 '05 #7
On Mon, 12 Sep 2005 20:09:31 -0700, chapolim-colorado wrote:
I like to keep my classes each in a separate file with the same name of
the class. The problem with that is that I end up with multiple imports
in the beginning of each file, like this:

from foo.Bar import Bar
from foo.Blah import Blah
from foo.Zzz import Zzz

What I'd like to do would be to replace it all by a single line:

from foo.* import *

Of course, that doesn't work, but is there a way to do something like
that?


"Doctor, it hurts when I do this."

"Then don't do that."

If putting one class per file causes you pain, then don't put one class
per file. The idea of packages is to make things easier for you, not
harder -- if you are having to fight the import mechanism, then perhaps
you need to rethink your design.

eg if you have a good reason for requiring one class per file, then one
possible work around would be to define a single "header" module
containing all those "from foo.Bar import Bar" statements, and then in
your actual module(s) call "from header import *". Watch out for circular
imports though.
--
Steven.

Sep 13 '05 #8
On Tuesday 13 September 2005 12:46 pm, George Sakkis wrote:
"Terry Hancock" <ha*****@anansispaceworks.com> wrote:
On Monday 12 September 2005 10:09 pm, ch***************@bol.com.br wrote:
I like to keep my classes each in a separate file with the same name of
the class. Apparently "foo" is already a package defined using __init__.py,
so you know about that part already.

Just change its contents to read:

from Bar import Bar
from Blah import Blah
from Zzz import Zzz


If you do this often or have lots of classes you want to import this
way, you could automate it:


(nice)
[...]
Or even better, forget about the braindead java restriction of one
class per file and organize your code as it makes more sense to you.


While this is good sound Python advice, there are good Human-readability
reasons for keeping a small number of classes per module. Python classes
certainly may not tend to blossum into the verbosity of their Java
counterparts, but I've still seen some pretty chunky classes (e.g. in
the Zope sources). So, the __init__.py approach and packaging is
still a good idea.

I particularly like the ability of __init__.py to craft the interface
layout of the module, independently of the file-structure that you
choose, as the best layout for the user may not be the best layout
for the developer.

I personally wouldn't favor automating this process unless you are
actually working with some kind of "plugin" design pattern. It's nicer
to have the fine control over the interface and be able to pick and
choose how things should be laid out. And the __init__.py code then
serves as a map for the developer to figure out where things are stored
(yes, they could also use grep, but every little bit helps).
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com

Sep 13 '05 #9
"Terry Hancock" <ha*****@anansispaceworks.com> wrote:
On Tuesday 13 September 2005 12:46 pm, George Sakkis wrote:
Or even better, forget about the braindead java restriction of one
class per file and organize your code as it makes more sense to you.


While this is good sound Python advice, there are good Human-readability
reasons for keeping a small number of classes per module. Python classes
certainly may not tend to blossum into the verbosity of their Java
counterparts, but I've still seen some pretty chunky classes (e.g. in
the Zope sources). So, the __init__.py approach and packaging is
still a good idea.


I agree, and that's what I had in mind with "as it makes more sense to
you". Big fat classes _are_ a good reason to keep them in separate
files, if nothing else, for readability reasons. What's braindead is
that java imposes a rule for what should be at best a good style
guideline.

George

Sep 13 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Steven K | last post by:
Hello, Is there a way to declare imports so that they don't have to be declared both in Master Page.vb and the Content Page.vb? For example, I have the following in the Master Page.vb Imports...
19
by: Tiraman | last post by:
Hi , I have an assembly that hold few class and few imports which are not used in all of the class's . so my question is when to use the "Imports XXX" And when to use this kind of statement...
1
by: Hul Tytus | last post by:
comp.infosystems.www.authoring.html simplifying mailto In form entry code, the "POST action=mailto:xxx@xxx.xxx" command requests a Subject and a CC heading from the reader -- in lynx that is, I...
1
by: Arpan | last post by:
What's the difference between "Imports" & "Inherits"? For e.g. both the codes below work without any errors: Imports System Imports System.Data Imports System.Web.UI Namespace Constructors...
0
by: steve | last post by:
If you think you can easily translate most relational division problems to sql you should write a book. If your not even sure what relational division even is or how it can do done in a sane way...
1
by: Thomas Wittek | last post by:
Hi! Is there any possibility/tool to automatically organize the imports at the beginning of a module? I don't mean automatic imports like autoimp does as I like seeing where my...
5
by: kimiraikkonen | last post by:
Hello, I want to ask about "imports" statement. Some projects must be inserted with "imports xxxx" statements before beginning coding. But how do i know when to use or do i have to use "imports"...
0
by: Kay Schluehr | last post by:
Since their introduction in Python 2.5 I only reviewed the new "relative import" notation briefly by reading the "What's new in Python 2.5" article. Now I wanted checkout if I get comfortable with...
3
by: Mohamed Yousef | last post by:
Hello , The problem I'm asking about is how can imported modules be aware of other imported modules so they don't have to re-import them (avoiding importing problems and Consicing code and...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.