| |
| |
| |
|
Page: 1 2 3
Comments:
<0> hello
<0> what's the difference between cl*** data attributes defined in the cl*** body and in the cl*** function?
<0> err, in *a* cl*** function
<1> do you mean:: cl*** C: x =1
<1> vs.:: cl*** C: def f(self): self.x = 1
<1> ?
<0> yes, exactly
<1> the difference is that the cl*** attribute is shared by all instances
<0> oh, i see
<0> so there's actually one instance of the attribute and all the cl*** instances point to it?
<0> i.e. when i change that, it changes in all instances change?
<0> -change
<1> only if you change the cl*** attribute
<0> yes, i see
<0> ok, thanks a lot :)
<1> if you do a self.x = 2 in an instance, that just overrides it in the instance
<1> it's the way Python does attribute lookup, it checks instances first, then cl***es, then parents
<0> ah, i see
<0> so i should declare all the instance variables in functions with .self
<0> err, self.
<1> well in a method, x (not self.x) is just a local variable (or maybe a global if there's one found)
<1> cl*** C: def f(self): x = 1
<1> doesn't do anything
<1> creates a local variable x, chucks it
<0> well yes
<0> hmm, wait
<0> look at this http://rafb.net/paste/results/WDDCSC78.html
<0> this prints 3
<1> yes
<1> because you've overriding it in the instance, not the cl***
<1> test is the cl***, hi & ho are instances
<0> oh hmm
<0> oh
<0> so i have to make a set() function in the cl*** to change it?
<0> like, def set(number): test = number?
<0> err, def set(self, number): test = number?
<1> you want to change the cl*** attribute?
<0> yes
<1> just do it, then: test.myvar =3
<1> test is the cl***, hi & ho are instances
<0> oh right, i didn't know you could just change the cl*** directly
<0> can you also call functions in a cl*** without instantiating the cl*** first?
<1> yeah, you can do whatever you like
<1> not without making them staticmethods
<1> cl*** C: @staticmethod; def f(): print "hi"
<1> C.f()
<0> ahh
<0> hmm
<0> well i see why i can't call them, they need a reference for the "self" argument
<1> yes
<0> but i can do test.set(cl***instance, 3)?
<1> yep
<0> if i p*** it manually?
<0> aha
<1> in fact that's typically what you'll do for parent cl***es
<0> aha
<0> i'll read up on the staticmethod thing, it's a bit peculiar
<1> if you want to call the method in a parent cl***, you'd do something like: cl*** LeafCl***(ParentCl***): ... def method(self): ParentCl***.method(self); ...
<1> it's mostly to emulate static methods from other languages like C++
<1> you can always just make it a global function
<1> staticmethod just makes it so you can call it from either the cl*** (test.f()) or an instance (hi.f()) and they'll both work
<0> ah, is that why i couldn't call a parent function with self.ParentFunction?
<1> yep
<1> self.method(...) will just reference the method in the CURRENT cl***
<0> oh, i see
<1> basically all attribute/method lookup is the same: you look in the instance, then the cl***, then the base cl***es
<1> so it'll find it in the cl*** before it finds it in the parent cl***es
<0> why doesn't it look in the parent cl*** if it doesn't find it in the current cl*** though?
<1> well if there isn't one in the main cl***, then it should; something else was probably wrong
<0> hmm
<0> here it is: http://rafb.net/paste/results/YeDbS471.html
<0> oh hm :(
<0> self.la :(
<0> right, ok
<0> interesting
<0> python is amazing
<2> re
<1> right
<1> the key to Python's OO handling is that it's so ridiculously simple but yet it can still do everything you want it to
<0> exactly
<0> how do they do that :P
<1> since Python's dynamic, it has to be more explicit than it might be in other languages, but that's actually a good thing :-)
<1> heh
<0> by the way, do you have any experience with Twisted?
<1> not particularly
<1> you'd probably want to talk to the #twisted guys in freenode for that
<1> if you can stand them long enough to get any help
<0> exactly :(
<2> are they a bit twisted somehow, then?
<1> insufferable would be a good description
<1> they actually had control of this channel (via a bot and some sympathetic ops) a few years back, it was nightmarish
<0> hmm, it disconnected me
<2> The proper idiom to bind enumerated constants to globals() ?
<1> how do you mean?
<1> RED, WHITE, BLUE = range(3) ?
<2> bingo
<1> there are some wacky enumerated type cookbook patterns
<1> usually I just put them in a cl***
<1> cl*** Color: RED, WHITE, BLUE = range(3)
<1> if approrpiate
<1> aprprorpoaororrorp
<2> there will be a lot of them (experimenting with wxWindows and it seems that every stinking object must have an ID...) and I was initially thinking something that'd scale better
<3> use less stinking objects :P
<2> e.g. enumerate() over a list of strings (which would represent the eventual symbol names)
<1> if you need a unique ID generator there are other approaches
<1> even if it's just a counter and you call .next
<2> xihr: It looks like I'll have to refer to some of the objects later by the id
<2> I could save certain objects' ids locally/globally of course
<1> yeah
<1> well if the objects are persistent you can always use id(anObject)
<2> I don't know why they need the IDs, they could just internally use implicit id() calls to satisfy wxWindows requirements
<1> the details of what the right thing to do really depends on the semantics of what kinds of IDs you need and how they're supposed to behave
<2> That's partially blurry still, as I'm not very intimately knowledgeable about wx yet
<1> I haven't heard this complaint about wxWindows before, so maybe you're just dealing with a lower-level API than you need to be
<1> but I'm just speculating
<2> but it seems that every object must have an ID and some things, like binding events requires using of them
<1> maybe there's some helpful support for that management that you haven't encountered yet
<2> much possible
<2> the IDs are in the C++ API but they seem to be included in the Python API too:
<2> http://www.wxpython.org/docs/api/wx.TreeCtrl-cl***.html
<2> find __init__
<2> ha
<2> ID defaults to -1
<2> perhaps that'll default to something sensible
<2> _now_ i spotted that
<0> ah, xihr, maybe you can help me
<0> are you there?
<1> y
<0> i am writing a script that is able to load some functions from a textfile and call them
<0> and I want to provide callbacks, so it can access a few functions in my script
<0> so I create a cl*** with all the callback functions and create an instance called "callback"
<0> so it can do"callback.Send('text'"
<0> )
<1> right
<0> and I do exec(textfile, {}, {"callback": callback})
<0> but this only works sometimes
<0> now I changed that dictionary to the local namespace and it works
<0> but I don't know why and I don't know what could break
<0> i mean, if you have a bunch of functions, wouldn't you expect the globals to be in all of them?
<1> well you're setting the globals to nothing
<1> do you mean exec or execfile?
<0> exec, I'm p***ing a string as the textfile variable
<0> hmm, i was p***ing an empty dictionary as the locals... but I couldn't omit it, that didn't work
<1> the second argument to exec is the globals, you're p***ing in {}
<1> so you're explicitly telling it that there should be no globals
<1> instead just do:: exec textfile
<1> exec 'print "Hello"'
<1> that's certainly valid
<0> oh man, i misread the documentation :(
<0> i had read it as exec(string, locals, globals)
<1> :-)
Return to
#python
or
Go to some related
logs:
#unixhelp
mssql signed int
#sql
skeedaddy wav
v1tnam
#computers
#flash
how do you know what kind of goddamned day
#3dsmax
#visualbasic
|
|