[Tutor] Syntax when using classes question.
Chris Hengge
pyro9219 at gmail.com
Sat Nov 11 10:42:55 CET 2006
Oops... should have said this...
pyForge.promptForge.prompt()
TypeError: unbound method prompt() must be called with promptForge instance
as first argument (got nothing instead)
^ Thats why... I have to use :
import pyForge
pyForge.promptForge().prompt()
On 11/11/06, Chris Hengge <pyro9219 at gmail.com> wrote:
>
> >So why did you use two sets of parenthesis here?
> >Are you completely sure you understand everything that's happening here?
>
> pyForge.promptForge.prompt()
> TypeError: unbound method prompt() must be called with promptForge
> instance as first argument (got nothing instead)
>
> ^ Thats why... I have to use :
> import pyForge
> pyForge.promptForge().prompt
>
> >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?
>
> Because I was trying to get a grip on classes and OOP... =P
> pyForge for lack of a better description is kinda like my own
> mini-framework. It's basically all the methods(functions?) that I've
> basically rewritten in each of my python files that I grouped together into
> classes by functionality. For example, pyForge has class fileforge which has
> two methods, one for writing, and one for reading files. Each takes a few
> different parameters but it makes an entire block of code transparent so
> that when I'm trying to show someone my code at work its less to look at.
> There is a class for a "console based splashscreen" called promptForge which
> has a "EULA" mode enabled by bool and takes a few parameters. I've also got
> zipForge which is very similar to my fileForge, but zips/unzips. I might add
> a few more things that I've repeated... It was mainly an attempt at learning
> classes, and I wanted all my re-usable code to be centralized so I didn't
> keep opening scripts and cutting and pasting.
>
>
>
> On 11/10/06, Luke Paireepinart <rabidpoobear at gmail.com> wrote:
> >
> > 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
> > >
> > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tutor/attachments/20061111/296fd8f1/attachment-0001.htm
More information about the Tutor
mailing list