Where to "import"?

[Paulo da Silva]

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

[Terry Reedy]

"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

[Bruno Desthuilliers]

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.

[Matimus]

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

[Ben Finney]

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

[Paulo da Silva]

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

Regards.
Paulo

[Paulo da Silva]

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

Regards.
Paulo

[Paulo da Silva]

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

[Bruno Desthuilliers]

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

[MonkeeSage]

On Mar 8, 5:49 pm, Bruno Desthuilliers
<[e-mail]>

>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

[MonkeeSage]

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

[Gabriel Genellina]

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

[MonkeeSage]

On Mar 8, 10:27 pm, "Gabriel Genellina" <[e-mail]>
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.

[Ben Finney]

"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

[Scott David Daniels]

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