[Tutor] Syntax when using classes question.

Luke Paireepinart rabidpoobear at gmail.com
Sat Nov 11 08:34:20 CET 2006


Chris Hengge wrote:
> As for saving memory.. I'm not particularily concerned since all my 
> systems have 2gb...
> Also, before python I was writing C# database front ends (nothing 
> amazing) and I'm not even going to compare python's 10mb overhead to 
> .net's 45mb+. I was mostly just curious if it would save the memory in 
> the same manner.
>
> As for using modules... I'm actually looking at my real code right 
> now.. (need to not reply to these emails while at work when I can't 
> really see the code)
> in my pyForge module (simple script to hold my common used objects 
> basically) there is a class promptForge, that contains a method prompt 
> <-- I know this is a great name =P....
> To call it:
> import pyForge # module name
> promptForge.prompt() # Class.method
> will tell me promptForge is undefined.
> so I use:
> promptForge().prompt()
> will tell me promptForge is undefined
Yeah, it's unidentified because it only exists in the imported module's 
namespace.
> so I use:
> pyForge.promptForge().prompt() # module.class.method
So why did you use two sets of parenthesis here?
Are you completely sure you understand everything that's happening here?

pyForge. -> now we're working in the module's namespace.
promptForge -> the class you're targeting in the pyForge namespace
() -> create an instance of the class using the __init__ method.
.prompt -> get the method 'prompt' from the instance of the class you 
just created.
() -> execute this method.

So why are you creating an instance of promptForge here?
> this works. (I just did all this while writing this email.)
Yeah, it works, but is it necessary?
> When I use:
> import random
> random.random () #This does its thing... most modules only have 
> module.whateverThisIs(params)
> in my code I've got module.class().method(params)... Am I not 
> conforming to some sort of module standard?
You're just creating an instance when you probably don't mean to.
> Are modules supposed to only be filled with methods,
No.
Then they would be called functions :)
methods are functions inside classes that act upon the class' data 
members (I.E. variables)
They're different terms so that people will know what you're talking about.
> using the module file itself as the seperation layer in place of using 
> a class?
Yeah, do that if you want just functions.
Do you want just functions?
I haven't seen your pyForge class, but if you're not using any OO features,
like the magical 'self' or the different __repr__, __str__, 
__getitems__, etc. methods,
then why is it in a class in the first place, and not just functions?
You can have a module of functions if you want.
You can have a module of variables if you want.
a module is just the same as having all the stuff declared in your 
program, except you refer to it all by module name.

#----- config.py
a = 1
#-----
#---- test.py
import config
print config.a
#------
etc.
>
> FYI... I dont know where it happened, but these last few e-mails are 
> off tutor.
Oops, yeah.  This one is forwarded to tutor and if anyone wants to see 
the previous discussion you can check the reply-stuff below.

HTH,
-Luke
>
> On 11/10/06, *Luke Paireepinart* <rabidpoobear at gmail.com 
> <mailto:rabidpoobear at gmail.com>> wrote:
>
>     Chris Hengge wrote:
>     > Alright, that all makes sense other then one part...
>     >
>     Okay! I'm shivering with anticipation :)
>     > I'm all for you saying to just use:
>     > import module
>     > module.class.method ()
>     > I agree this code is easier on the eyes down the road...
>     >
>     > but...( And this might be old world C++ coming in and shading my
>     view)
>     > In c++ you would be specific aka from module import class so
>     that you
>     > could conserve memory by not importing the entire library. Is this
>     > also true for python?
>     Ah, well, now we step into sacred territory.
>     >_>.
>     The long and short of it is, yes, importing the whole module uses
>     more
>     memory.
>     It shouldn't use significantly more memory.
>     If you're so constrained for memory that you're considering not using
>     'import class' just for this reason,
>     then you'll be fretting about the 10 mb of overhead (or whatever) the
>     Python interpreter takes up, I think :)
>
>     In general, in Python, consider "If it makes it easier on me and the
>     speed impact is not noticeable, why would I make it hard on myself?"
>     premature optimization is the root of all evil.
>     In this case, I wouldn't even consider the memory usage in deciding
>     which syntax you like better.
>     >
>     > Final question on the topic that hopefully has a clear answer =P
>     Oh, let's hope. *crosses fingers*
>     > When writing a module, is there some special way to do it? Like, do
>     > they use only classes with no methods inside? Or do they only use
>     > methods?
>     > I ask because my pyForge is Class > Methods and to use it I have
>     to say:
>     > import module
>     > module().class().method(stuff)
>     Are you sure? :D
>     You should never have to do this.
>     if you import module,
>     then everything inside of module is accessed the same way it would
>     be if
>     it were in your program,
>     just with a 'module.' prepended to it.
>     Imagine it like this.
>
>     #-----
>     #test.py
>     def aFunction():
>         print "hello"
>     aFunction()
>     #-----
>     obviously outputs hello.
>
>     Now consider these two files.
>
>     #-----
>     # module.py
>     def aFunction():
>         print "hello"
>     aVariable = "hi"
>     #------
>     how would you use this in your test.py script?
>
>     #-----
>     #test-version2.py
>     import module
>     module.aFunction()
>     print module.aVariable
>     #-------
>     You'll see
>     "hello
>     hi"
>     as the output for this script.
>
>     The 'import module' syntax  you can imagine as it creating a new
>     variable
>     that points to the _entire_ script 'module.py' and everything
>     inside of it.
>
>     So I don't think you'd ever have to do
>     'module().class().function()'
>     in fact, I know you would never need to do that.
>     A simple test:
>
>     import random
>     random()
>
>     raises a TypeError: 'module' object is not callable.
>
>     Do not think of a module as a class, cause it's not.
>     it's just a separate namespace.
>     So the 'from module import *' just says to get rid of that extra
>     level
>     of namespaces
>     that isolates those module functions from overwriting or interfering
>     with my own functions,
>     and just put them all as global, and trust me not to accidentally
>     overwrite them later.
>
>     >
>     > but when I go to use most of the "standard libraries" I can just
>     write
>     > something like
>     > import module
>     > module.method/class?(stuff)
>     Yeah.  you should always have to have a module., never a
>     module()., as I
>     hope the above explanation clarifies.
>     >
>     > Thanks again for your patience and clear answers Luke!
>     Sure!  It helps me to think about things like this too :)
>
>     Also, one final thing:
>     You can have a class that you don't instantiate but still create
>     instances of inner classes.
>
>     for example,
>     >>>
>     class foo(object):
>         class bar(object):
>             def __init__(self):
>                 print "Initializing bar!"
>
>     >>> foo.bar ()
>     Initializing bar!
>     <__main__.bar object at 0x00B536D0>
>     >>> foo
>     <class '__main__.foo'>
>     >>> foo()
>     <__main__.foo object at 0x00B53830>
>     >>> foo().bar()
>     Initializing bar!
>     <__main__.bar object at 0x00B53890>
>
>     You see, there's really no reason to initialize this class ('foo'),
>     because 'foo' is just holding the 'bar' class for us.
>     yeah, you can initialize 'foo' if you want, but it does exactly
>     the same
>     thing uninitialized, because it has no instance methods or variables,
>     or, in other words, nothing with 'self' in it.
>     I just thought of this because of your
>     "
>     I ask because my pyForge is Class > Methods and to use it I have
>     to say:
>     import module
>     module().class().method(stuff)
>     "
>     comment.
>     Let's assume you meant
>     module.class().method(stuff)
>     since module() raises an exception :)
>     so if you were doing this, it would mean on each call,
>     you're creating an instance of the class called 'class' and calling a
>     method on that instance,
>     but you're not storing the instance anywhere, so it's just
>     disappearing.
>     remember when we were talking about that before?
>     It's possible that you need to instantiate it but not keep a copy
>     around, but it's probable that this isn't what you wanted to do,
>     and you just put the () cause you thought they needed to go there.
>
>
>     HTH,
>     -Luke
>
>



More information about the Tutor mailing list