Question regarding naming convention

[michael]

Hello,

Apologies if this seems like a trivial question, but it would help me
with my python, coming from a Java background.

What is the preferred naming convention for a .py file, that contains a
class ? For example, if I have one class (MyClass), I wouldn't really
want to put it in myclass.py, as I'd end up referencing myclass.MyClass
(unless I use the import-from which I'm trying to avoid).

I'm also not sure about putting several unrelated classes in the same
..py file - It could just be Java talking, but it seems odd.

Thank you for any ideas.

Michael.

 

[John J. Lee]

http://www.python.org/doc/essays/styleguide.html#names
<quote> [...]
"Packages" (groups of modules, supported by the "ni" module) generally have
a short all lowercase name.
</quote>

[...]

Also note the 'ni' module is long gone, replaced by what is now the
standard import mechanism.


John

 

[michael]

http://www.python.org/doc/essays/styleguide.html#names

<snip quote>

Yeah, thanks for the quote. Unfortunately, this still leaves me with
syntax that's a bit unfriendly. Taking the StringIO class as an example,
I can either write:

import StringIO
s = StringIO.StringIO()

or:

from StringIO import StringIO
s = StringIO()

Both of the above seem to overcomplicate the syntax. Of the two, I
prefer the second, but I'm sure I've read on c.l.py that the
from..import.. version is not a preferred way of doing things.

Is there no way to write a class, such that the statement:

import MyClass

would dynamically import the MyClass class from MyClass.py ?

It just surprises me that there isn't a neater way around this, as
Python seems to encapsulate most everything else in a simple way.

Thanks,

Michael.

 

[John J. Lee]

Yeah, thanks for the quote. Unfortunately, this still leaves me with
syntax that's a bit unfriendly. Taking the StringIO class as an
example, I can either write:

import StringIO
s = StringIO.StringIO()

or:

from StringIO import StringIO
s = StringIO()

Both of the above seem to overcomplicate the syntax. Of the two, I

Well, one is simpler when you only use StringIO.StringIO once or
twice, and the other is simpler when you use it lots of times.
Really, there are two issues, I suppose. First, the second form has
the convenience of shorter names. Second, the first form is useful
where somebody reading your code would otherwise have to keep
referring to your imports to see where names came from, or might be
confused by similarly-named classes in different modules. Third, ease
of switching names -- sometimes it's convenient to be able to swap

from StringIO import StringIO

to

from cStringIO import StringIO

And have your code work unchanged. OK, three issues.

A fourth issue is that it's nice not to mix the two styles, to avoid
confusing readers.

prefer the second, but I'm sure I've read on c.l.py that the
from..import.. version is not a preferred way of doing things.

Nothing un-preferred about 'from foo import bar'. What is discouraged
is 'from foo import *' (that's a literal *, if you haven't seen that
syntax before -- see the tutorial). It is useful sometimes, though.
In PyQt, for example.

Is there no way to write a class, such that the statement:

import MyClass

would dynamically import the MyClass class from MyClass.py ?

Well, maybe (I'm vaguely aware that there's an import hook of some
kind). *Nobody* would thank you for it, other than as a joke.

It just surprises me that there isn't a neater way around this, as
Python seems to encapsulate most everything else in a simple way.

Modules are useful, and explicit is better than implicit.


John

 

[Steven Taschuk]

Quoth michael:
[...]

Is there no way to write a class, such that the statement:

import MyClass

would dynamically import the MyClass class from MyClass.py ?

Not recommended, but:

# MyClass.py
import sys
class MyClass(object):
pass
sys.modules['MyClass'] = MyClass

This is a dangerous hack; I'm sure there's lots of code which
expects sys.modules to contain only modules.

Better, if you really want this kind of behaviour, is to write a
custom __import__ function. See

It just surprises me that there isn't a neater way around this, as
Python seems to encapsulate most everything else in a simple way.

It's fairly rare for a module to contain only one entity of
interest to importers. (StringIO is unusual in this respect.)

Since you're coming from a Java background, you might try thinking
of modules as analogous to leaf-level Java packages. For example,
where Java has
java/
util/
LinkedList.java
AbstractList.java
# etc.
Python would have
java/
__init__.py # to make java a package; probably just has docstring
util.py # contains classes LinkedList, AbstractList, etc.

 

[Fredrik Lundh]

Both of the above seem to overcomplicate the syntax. Of the two,
I prefer the second, but I'm sure I've read on c.l.py that the from.
import.. version is not a preferred way of doing things.

"from ... import *" is usually a bad idea.

"from SomeClass import SomeClass" is an excellent idea.

more here:

http://effbot.org/zone/import-confusion.htm

</F>

 

[Hans Nowak]

Both of the above seem to overcomplicate the syntax. Of the two, I
prefer the second, but I'm sure I've read on c.l.py that the
from..import.. version is not a preferred way of doing things.

Is there no way to write a class, such that the statement:

import MyClass

would dynamically import the MyClass class from MyClass.py ?

It just surprises me that there isn't a neater way around this, as
Python seems to encapsulate most everything else in a simple way.

Not sure if this is what you're after, but:
mod = __import__(name)
obj = getattr(mod, name)
globals()[name] = obj

# import the StringIO object from the StringIO module
# is it in the global namespace? yes:['StringIO', '__builtins__', '__doc__', '__name__', 'importobj']

Putting something into globals() is a bit of a kludge, though. You're probably
better off using from x import x.

Cheers,