| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Comments:
<0> so __str__ would be called by the built-in function str()
<0> and __len__ is called by len()
<1> and __call__ is called by parens, and __getitem__ & __getslice__ is used for [] 's to behave like a list
<1> and __eq__ is called by ==
<2> maybe this is a better example. if you were an object and I dissected you under autopsy, I would find a __heart__, __liver__, __brain__, __etc__ in other words, every object, tiger, lion or bear, have these __special_attributes__ e.g. (__stripes__, __crown__, __hibernation__) it's these special methods that make these objects unique... heh
<1> etc
<1> vbgunz: ok
<1> vbgunz: if you want to see what methods an object has you can use the built in dir function on it
<0> hmm... not really, vbgunz :(
<0> those things would just be regular attributes
<0> I mean, you can call them __heart__
<0> but the reason why __init__ __call__ etc. are considered "special" is because they are used specifically by python
<2> polpak: yeah, am a bit familiar with dir. I used it in my paste to get all attributes from the re mod
<1> vbgunz: ah, yes the __foo__ naming convention doesn't actually do anything special
<2> Hamled: ok, am conjuring up another analogy...
<0> well, except that without the ending __, if you just did __foo, it'd be harder to reference it from outside the object, but that's a bit complicated for this conversation :/
<2> polpak: I know I can have my own __vars__ but this convention is best left alone as part of Pythons special methods...
<0> I kind of understand what you're getting at
<2> Hamled: __name turns to _cl***__name or something similar huh though I would agree that would steer this conversation right out of the window
<0> yeah, pretty much
<0> and to some degree all objects (if they are derived from type/object instead of being old-style cl***es) have some of these special attributes
<3> you should keep in mind that the fact alone that an object has a __call__ according to dir() or inspect, isn't enough to make it callable.
<0> but I wouldn't necessarily consider most of them to be a part of every object, and I also wouldn't say that the special attributes make an object unique
<0> Yhg1s, no?
<4> http://www.johnsadowski.com/big_spanish_castle.html
<3> Hamled: no. it can have a __call__ that raises a TypeError :)
<1> heh
<0> Yhg1s, but that's still calling __call__ :)
<3> anyway, it's just an example. Note, for instance, that int objects have '__setattr__' and '__delattr__' method, but you can neither set nor delete attributes of ints.
<0> oh, I see what you mean
<0> (as to the __call__)
<0> callable() doesn't check to make sure that the __call__ itself is callable, which I guess would be sort of an infinite loop problem
<3> so, don't get hung up over the attributes. they're implementation details. If you want to know whether something supports an operation, try the operation, don't look at methods it has.
<3> Hamled: no, callable() is separate from __call__. callable() is more likely to be right.
<0> apparently not
<0> I made an object with __call__ = 2
<0> and callable() said the instance was callable
<3> yes, but the Python world doesn't exist solely of Python cl***es.
<0> well maybe it should >:(
<3> that would be a kind of chicken-egg problem, then, wouldn't it?
<3> besides the horrendous performance you'd have.
<0> I'm just joking with you, but of course the existance of __setattr__ and __delattr__ doesn't mean that their functionality is granted to you, their existance is actually just as likely to be used to deny you access
<0> err, the default functionality, from type... yeah.... I didn't really say that right
<2> ok, am going back to the lab, I need to get better with hasattr, getattr, setattr, vars, isinstance, callable, etc and am studying them now. along with a few others!
<2> thank you fellas!
<0> I had written a function a little while ago that would replace __setattr__, __getattr__, and __delattr__ for any cl*** with the standard ones from type, not sure how well that would work for fooling python
<3> Hamled: why would you do that?
<0> I was just testing out something
<0> something to do with __slots__ cl***es
<0> I was bored
<3> well, it doesn't fool python.
<3> it's not special setattr/delattr methods that make an object not have attributes.
<0> oh :(
<5> can someone help me finding out why a thread is never started ?
<5> i do thread.start_new_thread(self._auth_thread, ())
<5> the _auth_thread medthos is never called
<6> asabil: what des start_new_thread do?
<0> python is probably the only language I've actually been able to have fun with just mesing around with the internals of how the language/virtual machine works
<5> konrads, http://docs.python.org/lib/module-thread.html
<6> asabil: well, my point was that i'd usually do something along theese lines: threading.Thread(target=__run,args=(self,)).run()
<6> to threadify a function
<5> okey thanks
<5> konrads, thanks it works :)
<5> but why the first one didn't ?
<7> any ideas on how to change a cl*** type? -- http://pastebin.com/706089
<8> gakman, you don't. why would you want to do that?
<7> i have a server sending a pickle of an object instance to a client, but the server is sending a 'fruit' and the client can only make an 'apple'
<7> (in reference to the pastebib)
<7> i only thought it was possible because of int(5.0)
<8> first pickle is not a good idea for serializing data between client and server. second, if your client can only handle apple, then send it an apple.
<7> ah but the server cant make an apple :)
<7> ok ill forget the pickle idea, thanks
<8> so make an apple constructor on the client.
<9> gakman: are you aware of the security implications of using pickle?
<7> yes teratorn!
<9> gakman: great :)
<7> soyt: i will only send the attributes of the cl***, and make the client instantiate an Apple and populate the attributes
<8> gakman, yes, that is better.
<7> teratorn: im paranoid a security :) this is just a fool-around game im making
<7> a=about
<7> ok soyt, thanks
<0> gakman, why doesn't a.__cl***__ = apple work?
<0> I just tried it on my own and it worked fine
<7> oh it did? i printed a and it didnt seem to change
<7> i didnt test the cl*** out of course
<10> Don't shoot me. I'll subscribe for one second to the philosophy of "right tool for the job." I only know Python this far. But, is there any place (URL) that explains in a good, illustrative way the differences between PHP, perl, ruby, python and as many other languages as possible?
<7> Hamled: http://pastebin.com/706108 <- that doesn't work for me, is that what you were trying?
<0> well you are doing a.__cl***__ == apple
<0> you should be doing a.__cl***__ = apple
<11> from a python point of view, you could check the comp.lang.python archives
<7> top222: http://en.wikipedia.org/wiki/Comparison_of_programming_languages
<10> Thank you both
<7> ah crap :)
<7> Hamled, thanks, it was a f'up from my end...
<0> I wasn't sure if you were doing that on purpose to test something or other (if you were testing you'd use issubcl***)
<7> just a typo :)
<0> aye
<0> I still wouldn't use pickling across the network
<7> yeah, im just lazy that's all :)
<7> ill change it later...
<0> there are some nice transparent object sharing thigns out there
<7> oh i see, ill investigate
<12> gakman: See Pyro for RPC in Python. It can also transport code across the network.
<0> (I wouldn't trust it though... y'never know)
<13> Hamled, there is SSL encryption you know
<0> hmmmm... still, *puts his tinfoil hat on*
<0> irrational fears are your friend
<0> like the irrational fear that your python applications will suddenly fall apart because a compiler has not type-checked everything!
<14> Hello
<0> hi
<14> Actual life in a chat room, I should report back to Houston. :)
<15> GC1CEO: Hamled is a bot
<14> heh
<14> Thats more alive then most.
<0> GC1CEO: Leeds is a bot
<16> it's life, but not as we know it ;)
<7> JIM!
<15> there's Klingons on the starboard bow!
<7> i take it most of you are poms :)
<14> Any chance that I can ask a quick wxPython question without being told to rm -rf * ?:)
<7> rm -rf / is better
<15> try it, you might like it
<15> GC1CEO: if you don't ask your question, no-one can answer it, or alternatively tell you where to stick it :-)
<0> I can tell people where to stick it even fi they dont' ask questions
<14> Either way I suppose I should risk it. Looking for how to set a wxPython control unselectable/greyed out.. I have done this in plenty of Java applets but being new to Python I haven't found mention of it in the wxPython guide I have been working off.
<0> I'm just too much of a nice guy to do so :)
<14> Any suggestions ?:)
<0> I've got no idea
<0> have you checked controls for a disable attribute?
<14> checking as we speak, although it may be in some parent I have yet to check.
<15> never used wxpython myself
<14> I would be very surprised if it didn't exist because such a thing exists in every other OOP I have worked with.
<0> wxWindow::Disable
<14> disables the window.. not neccesarily an individual control.
<14> least far as I can tell.
<17> (Or wxWindow.Enable(False))
<0> wxControl is a child cl*** of wxWindow
<17> GC1CEO, all controls derive from wxWindow, afaicr
<14> true true
<14> ah
<14> brain is partly asleep.
<14> duh duh.
<0> so any control you have will have Disable/Enable
<14> yep
<14> The hamster that controls most of my brain now remembers.
<0> hmph, Self actually used an animated user interface back in 95
<18> how can I get a snapshot of the structure of an xml document, so I know which elements I want to use?
<18> am using xml.dom.minidom
Return to
#python
or
Go to some related
logs:
perl quantifier follows nothing
#ubuntu
#perl
#css
totalwallpaper.com
ubuntu gst-register command not found
#perl
ositopunky
CONNMARK --restore-mark iptables: No chain/target/match by that name
etch wpa_supplicant setup
|
|