[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