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* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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 > > _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
