>So why did you use two sets of parenthesis here?<br>>Are you completely sure you understand everything that's happening here?<br><br> pyForge.promptForge.prompt()<br>TypeError: unbound method prompt() must be called with promptForge instance as first argument (got nothing instead)
<br><br>^ Thats why... I have to use :<br>import pyForge<br>pyForge.promptForge().prompt<br><br>>Do you want just functions?<br>>I haven't seen your pyForge class, but if you're not using any OO features,<br>>like the magical 'self' or the different __repr__, __str__,
<br>>__getitems__, etc. methods,<br>>then why is it in a class in the first place, and not just functions?<br><br>Because I was trying to get a grip on classes and OOP... =P<br>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.
<br><br><br><br><div><span class="gmail_quote">On 11/10/06, <b class="gmail_sendername">Luke Paireepinart</b> <<a href="mailto:rabidpoobear@gmail.com">rabidpoobear@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Chris Hengge wrote:<br>> As for saving memory.. I'm not particularily concerned since all my<br>> systems have 2gb...<br>> Also, before python I was writing C# database front ends (nothing<br>> amazing) and I'm not even going to compare python's 10mb overhead to
<br>> .net's 45mb+. I was mostly just curious if it would save the memory in<br>> the same manner.<br>><br>> As for using modules... I'm actually looking at my real code right<br>> now.. (need to not reply to these emails while at work when I can't
<br>> really see the code)<br>> in my pyForge module (simple script to hold my common used objects<br>> basically) there is a class promptForge, that contains a method prompt<br>> <-- I know this is a great name =P....
<br>> To call it:<br>> import pyForge # module name<br>> promptForge.prompt() # Class.method<br>> will tell me promptForge is undefined.<br>> so I use:<br>> promptForge().prompt()<br>> will tell me promptForge is undefined
<br>Yeah, it's unidentified because it only exists in the imported module's<br>namespace.<br>> so I use:<br>> pyForge.promptForge().prompt() # module.class.method<br>So why did you use two sets of parenthesis here?<br>
Are you completely sure you understand everything that's happening here?<br><br>pyForge. -> now we're working in the module's namespace.<br>promptForge -> the class you're targeting in the pyForge namespace<br>() -> create an instance of the class using the __init__ method.
<br>.prompt -> get the method 'prompt' from the instance of the class you<br>just created.<br>() -> execute this method.<br><br>So why are you creating an instance of promptForge here?<br>> this works. (I just did all this while writing this email.)
<br>Yeah, it works, but is it necessary?<br>> When I use:<br>> import random<br>> random.random () #This does its thing... most modules only have<br>> module.whateverThisIs(params)<br>> in my code I've got
module.class().method(params)... Am I not<br>> conforming to some sort of module standard?<br>You're just creating an instance when you probably don't mean to.<br>> Are modules supposed to only be filled with methods,
<br>No.<br>Then they would be called functions :)<br>methods are functions inside classes that act upon the class' data<br>members (I.E. variables)<br>They're different terms so that people will know what you're talking about.
<br>> using the module file itself as the seperation layer in place of using<br>> a class?<br>Yeah, do that if you want just functions.<br>Do you want just functions?<br>I haven't seen your pyForge class, but if you're not using any OO features,
<br>like the magical 'self' or the different __repr__, __str__,<br>__getitems__, etc. methods,<br>then why is it in a class in the first place, and not just functions?<br>You can have a module of functions if you want.<br>
You can have a module of variables if you want.<br>a module is just the same as having all the stuff declared in your<br>program, except you refer to it all by module name.<br><br>#----- config.py<br>a = 1<br>#-----<br>#----
test.py<br>import config<br>print config.a<br>#------<br>etc.<br>><br>> FYI... I dont know where it happened, but these last few e-mails are<br>> off tutor.<br>Oops, yeah. This one is forwarded to tutor and if anyone wants to see
<br>the previous discussion you can check the reply-stuff below.<br><br>HTH,<br>-Luke<br>><br>> On 11/10/06, *Luke Paireepinart* <<a href="mailto:rabidpoobear@gmail.com">rabidpoobear@gmail.com</a><br>> <mailto:
<a href="mailto:rabidpoobear@gmail.com">rabidpoobear@gmail.com</a>>> wrote:<br>><br>> Chris Hengge wrote:<br>> > Alright, that all makes sense other then one part...<br>> ><br>> Okay! I'm shivering with anticipation :)
<br>> > I'm all for you saying to just use:<br>> > import module<br>> > module.class.method ()<br>> > I agree this code is easier on the eyes down the road...<br>> ><br>> > but...( And this might be old world C++ coming in and shading my
<br>> view)<br>> > In c++ you would be specific aka from module import class so<br>> that you<br>> > could conserve memory by not importing the entire library. Is this<br>> > also true for python?
<br>> Ah, well, now we step into sacred territory.<br>> >_>.<br>> The long and short of it is, yes, importing the whole module uses<br>> more<br>> memory.<br>> It shouldn't use significantly more memory.
<br>> If you're so constrained for memory that you're considering not using<br>> 'import class' just for this reason,<br>> then you'll be fretting about the 10 mb of overhead (or whatever) the<br>> Python interpreter takes up, I think :)
<br>><br>> In general, in Python, consider "If it makes it easier on me and the<br>> speed impact is not noticeable, why would I make it hard on myself?"<br>> premature optimization is the root of all evil.
<br>> In this case, I wouldn't even consider the memory usage in deciding<br>> which syntax you like better.<br>> ><br>> > Final question on the topic that hopefully has a clear answer =P
<br>> Oh, let's hope. *crosses fingers*<br>> > When writing a module, is there some special way to do it? Like, do<br>> > they use only classes with no methods inside? Or do they only use<br>> > methods?
<br>> > I ask because my pyForge is Class > Methods and to use it I have<br>> to say:<br>> > import module<br>> > module().class().method(stuff)<br>> Are you sure? :D<br>> You should never have to do this.
<br>> if you import module,<br>> then everything inside of module is accessed the same way it would<br>> be if<br>> it were in your program,<br>> just with a 'module.' prepended to it.<br>
> Imagine it like this.<br>><br>> #-----<br>> #test.py<br>> def aFunction():<br>> print "hello"<br>> aFunction()<br>> #-----<br>> obviously outputs hello.
<br>><br>> Now consider these two files.<br>><br>> #-----<br>> # module.py<br>> def aFunction():<br>> print "hello"<br>> aVariable = "hi"<br>> #------
<br>> how would you use this in your test.py script?<br>><br>> #-----<br>> #test-version2.py<br>> import module<br>> module.aFunction()<br>> print module.aVariable<br>> #-------
<br>> You'll see<br>> "hello<br>> hi"<br>> as the output for this script.<br>><br>> The 'import module' syntax you can imagine as it creating a new<br>> variable<br>
> that points to the _entire_ script 'module.py' and everything<br>> inside of it.<br>><br>> So I don't think you'd ever have to do<br>> 'module().class().function()'<br>> in fact, I know you would never need to do that.
<br>> A simple test:<br>><br>> import random<br>> random()<br>><br>> raises a TypeError: 'module' object is not callable.<br>><br>> Do not think of a module as a class, cause it's not.
<br>> it's just a separate namespace.<br>> So the 'from module import *' just says to get rid of that extra<br>> level<br>> of namespaces<br>> that isolates those module functions from overwriting or interfering
<br>> with my own functions,<br>> and just put them all as global, and trust me not to accidentally<br>> overwrite them later.<br>><br>> ><br>> > but when I go to use most of the "standard libraries" I can just
<br>> write<br>> > something like<br>> > import module<br>> > module.method/class?(stuff)<br>> Yeah. you should always have to have a module., never a<br>> module()., as I
<br>> hope the above explanation clarifies.<br>> ><br>> > Thanks again for your patience and clear answers Luke!<br>> Sure! It helps me to think about things like this too :)<br>><br>
> Also, one final thing:<br>> You can have a class that you don't instantiate but still create<br>> instances of inner classes.<br>><br>> for example,<br>> >>><br>> class foo(object):
<br>> class bar(object):<br>> def __init__(self):<br>> print "Initializing bar!"<br>><br>> >>> foo.bar ()<br>> Initializing bar!<br>> <__main__.bar object at 0x00B536D0>
<br>> >>> foo<br>> <class '__main__.foo'><br>> >>> foo()<br>> <__main__.foo object at 0x00B53830><br>> >>> foo().bar()<br>> Initializing bar!
<br>> <__main__.bar object at 0x00B53890><br>><br>> You see, there's really no reason to initialize this class ('foo'),<br>> because 'foo' is just holding the 'bar' class for us.<br>> yeah, you can initialize 'foo' if you want, but it does exactly
<br>> the same<br>> thing uninitialized, because it has no instance methods or variables,<br>> or, in other words, nothing with 'self' in it.<br>> I just thought of this because of your<br>> "
<br>> I ask because my pyForge is Class > Methods and to use it I have<br>> to say:<br>> import module<br>> module().class().method(stuff)<br>> "<br>> comment.<br>> Let's assume you meant
<br>> module.class().method(stuff)<br>> since module() raises an exception :)<br>> so if you were doing this, it would mean on each call,<br>> you're creating an instance of the class called 'class' and calling a
<br>> method on that instance,<br>> but you're not storing the instance anywhere, so it's just<br>> disappearing.<br>> remember when we were talking about that before?<br>> It's possible that you need to instantiate it but not keep a copy
<br>> around, but it's probable that this isn't what you wanted to do,<br>> and you just put the () cause you thought they needed to go there.<br>><br>><br>> HTH,<br>> -Luke<br>><br>>
<br><br></blockquote></div><br>