469,934 Members | 1,984 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,934 developers. It's quick & easy.

Where to "import"?

Hi!

If I have two files .py such as

m.py
from c import *
...
x=c()
...
os.any_method ...
...

c.py
class c:
def __init__(self, ...):
...
os.any_method ...
...
...

both using os module where should I put the "import os"? In both files?

Thanks
Paulo
Mar 8 '07 #1
14 1896

"Paulo da Silva" <ps********@esotericaX.ptXwrote in message
news:11***************@iceman.esoterica.pt...
| Hi!
|
| If I have two files .py such as
|
| m.py
| from c import *
| ...
| x=c()
| ...
| os.any_method ...
| ...
|
| c.py
| class c:
| def __init__(self, ...):
| ...
| os.any_method ...
| ...
| ...
|
| both using os module where should I put the "import os"? In both files?

I would even though having it in m.py is not *currently* necessary. Having
the import of os into m.py depend on the way you write and import c.py
looks fragile, and it certainly is a memory burden to remember that c does
so. Also, I probably would use 'import c' instead.

tjr

Mar 8 '07 #2
Paulo da Silva a écrit :
Hi!

If I have two files .py such as

m.py
from c import *
avoid this kind of import except in an interactive interpreter and
eventually in a package __init__.py. Better to use either:

from c import c
or
import c
...
x = c.c()
...
x=c()
...
os.any_method ...
Then you need to import os
...

c.py
class c:
class C(object):

1/ better to stick to naming conventions (class names in CamelCase)
2/ do yourself a favor: use new-style classes
def __init__(self, ...):
...
os.any_method ...
...
...

both using os module where should I put the "import os"? In both files?
Yes. In your above example, it worked because of the "from c import *" -
and this is exactly why it's bad form to use this in a module (well:
that's one of the reasons why). Each module should *explicitly* import
all it's direct dependencies.

Mar 8 '07 #3
both using os module where should I put the "import os"? In both files?

You don't really have a choice, you have to import os in both files.
Python will only load the os module into memory once, but the import
statements are needed to add the os module to the c and m module
namespaces. The code in c.py cannot 'see' the code in m.py, even if it
was imported by m.py. The import command is not like #include in C, it
is not a code dump.

-m

Mar 8 '07 #4
Paulo da Silva <ps********@esotericaX.ptXwrites:
Hi!

If I have two files .py such as

m.py
from c import *
Best done as either

import c # then use 'x = c.c()'

or

from c import c

Using 'from foo import *' leads to names appearing in your current
namespace that are difficult to track to their origin by reading the
source code.
both using os module where should I put the "import os"? In both
files?
Yes. "import os" does two things of note:

- iff the module is not currently loaded and executed, do so
- bind the module object to the name "os" in the current namespace

The first step means that you're not losing anything by importing the
module wherever it's needed. The second means the module is available
for use within the current namespace.

--
\ "When cryptography is outlawed, bayl bhgynjf jvyy unir |
`\ cevinpl." -- Anonymous |
_o__) |
Ben Finney

Mar 8 '07 #5
Paulo da Silva escreveu:
This is to thank all the answers I got so far.
Now I understand perfectly how "import" works.

Regards.
Paulo
Mar 8 '07 #6
Paulo da Silva escreveu:
This is to thank all the answers I got so far.
Now I understand perfectly how "import" works.

Regards.
Paulo
Mar 8 '07 #7
Bruno Desthuilliers escreveu:
Paulo da Silva a écrit :
....
>>
c.py
class c:
class C(object):

1/ better to stick to naming conventions (class names in CamelCase)
Ok. Thanks.
2/ do yourself a favor: use new-style classes
I still have python 2.4.3 (The gentoo current version).
I didn't find this in my tutorial. Would you please enlight me
a bit about this (class C(object))? Or just point me out some doc
to read about.

Thank you.
Paulo
Mar 8 '07 #8
Paulo da Silva a écrit :
Bruno Desthuilliers escreveu:
>>Paulo da Silva a écrit :

...

>>>c.py
class c:

class C(object):

1/ better to stick to naming conventions (class names in CamelCase)

Ok. Thanks.
FWIW:
http://www.python.org/dev/peps/pep-0008/
>>2/ do yourself a favor: use new-style classes

I still have python 2.4.3 (The gentoo current version).
new-style classes came with Python 2.2.1 IIRC.
I didn't find this in my tutorial. Would you please enlight me
a bit about this (class C(object))?
Inheriting from the builtin class 'object' (or from any other new-style
class) makes your class a new-style class. new-style classes have much
more features than old-style ones. Like support for properties (computed
attributes). old-style classes are still here mainly for compatibility
with old code. While there not yet officially deprecated, you can
consider them as such.
Or just point me out some doc
to read about.
http://www.python.org/doc/newstyle/

HTH
Mar 8 '07 #9
On Mar 8, 5:49 pm, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.fr>
>1/ better to stick to naming conventions (class names in CamelCase)
Ok. Thanks.

FWIW:http://www.python.org/dev/peps/pep-0008/
By my reading, PEP8 doesn't specify CamelCase as preferred over the
other styles it mentions. non_camel_case is also considered good
style, as I understand (and is used all over the standard library).

Regards,
Jordan

Mar 9 '07 #10
Disregard my last message, I'm stupid. I totally missed that Bruno was
talking about classname. Bruno is exactly right.

Mar 9 '07 #11
En Fri, 09 Mar 2007 01:09:36 -0300, MonkeeSage <Mo********@gmail.com>
escribió:
>FWIW:http://www.python.org/dev/peps/pep-0008/

By my reading, PEP8 doesn't specify CamelCase as preferred over the
other styles it mentions. non_camel_case is also considered good
style, as I understand (and is used all over the standard library).
Class names should be CamelCase. Read it again, and notice the difference
between a "Descriptive" section and a "Prescriptive" one.

--
Gabriel Genellina

Mar 9 '07 #12
On Mar 8, 10:27 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
wrote:
Class names should be CamelCase. Read it again, and notice the difference
between a "Descriptive" section and a "Prescriptive" one.
Yes, I misread Bruno's comment (missed that he was speaking of class
names). Disregard my post.

Mar 9 '07 #13
"Gabriel Genellina" <ga*******@yahoo.com.arwrites:
Class names should be CamelCase.
Note that the term "camel case" has ambiguous usage. Some use it to
refer to *both* of "nameWithSeveralWords" and "NameWithSeveralWords".

I prefer to use the term "title case" to refer unambiguously to
"NameWithSeveralWords", leaving the term "camel case" to describe the
case with the humps only in the middle :-)

PEP 8 recommends TitleCase for class names. The use of camelCase for
instances and method names seems to come from (at least) Java, but PEP
8 prefers lowercase_with_underscores.

--
\ "My theory of evolution is that Darwin was adopted." -- Steven |
`\ Wright |
_o__) |
Ben Finney

Mar 9 '07 #14
Ben Finney wrote:
I prefer to use the term "title case" to refer unambiguously to
"NameWithSeveralWords", leaving the term "camel case" to describe the
case with the humps only in the middle :-)
The names "TitleCase" and "camelCase" might suffice here.

--
--Scott David Daniels
sc***********@acm.org
Mar 9 '07 #15

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Vio | last post: by
2 posts views Thread by Torsten Mohr | last post: by
5 posts views Thread by mark_galeck_spam_magnet | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.