On Jan 15, 8:06 pm, Helmut Jarausch <[EMAIL PROTECTED]> wrote:
> Unfortunately the links [2], [3] and [4] are not given,
Luckily, there's Google :)
[2] Article about MRO: http://www.python.org/download/releases/2.3/mro/
[3] Descriptor HowTo: http://users.rcn.com/python/download/Descriptor.htm
[4
Michele Simionato wrote:
> I really need to publish this one day or another, since these
> questions
> about super keeps coming out:
>
> http://www.phyast.pitt.edu/~micheles/python/super.html
Unfortunately the links [2], [3] and [4] are not given,
Helmut.
--
Helmut Jarausch
Lehrstuhl fuer N
On Jan 13, 5:51 am, Richard Szopa <[EMAIL PROTECTED]> wrote:
> On Jan 13, 8:59 am, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 12 Jan 2008 14:23:52 -0800, Richard Szopa wrote:
> > > However, I am very surprised to learn that
>
> > > super_object.__getattr__(name)(*args, **kwar
On Jan 14, 11:47 pm, Richard Szopa <[EMAIL PROTECTED]> wrote:
> Could you tell me what are the pros and cons of the two approaches
> (i.e. writing a decorator function and a decorator descriptor class)?
I prefer to use a class for introspection sake, since
there is no way to get information about
On Jan 14, 7:53 am, Michele Simionato <[EMAIL PROTECTED]>
wrote:
> I really need to publish this one day or another, since these
> questions
> about super keeps coming out:
>
> http://www.phyast.pitt.edu/~micheles/python/super.html
Please do. It is a very enlightening discussion, and I'm sure a bu
On Jan 14, 11:05 pm, thebjorn <[EMAIL PROTECTED]>
wrote:
> I don't remember if CLOS was changed to use C3 Linearization also, but
> the concept came from Dylan (http://www.webcom.com/haahr/dylan/
> linearization-oopsla96.html) and that's what is implemented in Python.
The Common Lisp ANSI standar
On Jan 14, 1:53 pm, Michele Simionato <[EMAIL PROTECTED]>
wrote:
> I really need to publish this one day or another, since these
> questions
> about super keeps coming out:
>
> http://www.phyast.pitt.edu/~micheles/python/super.html
Thanks, Michele! Your essay was enlightening [2]. Specially if yo
Michele Simionato <[EMAIL PROTECTED]> writes:
> I really need to publish this one day or another, since these
> questions about super keeps coming out:
>
> http://www.phyast.pitt.edu/~micheles/python/super.html
Yes, please. Your article has improved my understanding just from
skimming the main h
On Jan 14, 1:41 pm, Richard Szopa <[EMAIL PROTECTED]> wrote:
> On Jan 13, 3:31 pm, thebjorn <[EMAIL PROTECTED]>
> wrote:
>
> > They do, except for when it comes to what super(..) returns. It isn't
> > really an object in the sense that they're presented in the tutorial,
> > but rather a sort of pro
On Jan 12, 6:56 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Sat, 12 Jan 2008 15:47:05 -0500, Mike Meyer wrote:
> > There's an apparently common bug here: you don't want to pass super
> > self.__class__, but the class that the method is bound to.
>
> Given an instance met
On Jan 14, 1:41 pm, Richard Szopa <[EMAIL PROTECTED]> wrote:
> However, there's one piece that doesn't completely fit to the puzzle:
> why does getattr work? The help says:
>
> getattr(...)
> getattr(object, name[, default]) -> value
>
> Get a named attribute from an object; getattr(x, 'y')
On Jan 13, 3:31 pm, thebjorn <[EMAIL PROTECTED]>
wrote:
> They do, except for when it comes to what super(..) returns. It isn't
> really an object in the sense that they're presented in the tutorial,
> but rather a sort of proxy to the methods in the ancestor classes of
> the concrete object (self
On Jan 13, 1:51 pm, Richard Szopa <[EMAIL PROTECTED]> wrote:
> On Jan 13, 8:59 am, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 12 Jan 2008 14:23:52 -0800, Richard Szopa wrote:
> > > However, I am very surprised to learn that
>
> > > super_object.__getattr__(name)(*args, **kwar
On Jan 13, 8:59 am, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> On Sat, 12 Jan 2008 14:23:52 -0800, Richard Szopa wrote:
> > However, I am very surprised to learn that
>
> > super_object.__getattr__(name)(*args, **kwargs)
>
> > getattr(super_object, name)(*args, **kwargs)
>
> > are not eq
On Sat, 12 Jan 2008 14:23:52 -0800, Richard Szopa wrote:
> However, I am very surprised to learn that
>
> super_object.__getattr__(name)(*args, **kwargs)
>
> getattr(super_object, name)(*args, **kwargs)
>
> are not equivalent. This is quite odd, at least when with len()
> and .__len__, str() an
On Sat, 12 Jan 2008 15:47:05 -0500, Mike Meyer wrote:
> There's an apparently common bug here: you don't want to pass super
> self.__class__, but the class that the method is bound to.
Given an instance method, is it possible to easily determine what class
it is defined in?
I thought the im_cla
On Jan 12, 9:47 pm, Mike Meyer <[EMAIL PROTECTED]>
wrote:
> The same way you call any object's methods if you know it's name":
>
> getattr(super_object, name)(*args, **kwargs)
Thanks a lot for your answer!
However, I am very surprised to learn that
super_object.__getattr__(name)(*args, **kw
On Sat, 12 Jan 2008 10:45:25 -0800 (PST) Richard Szopa <[EMAIL PROTECTED]>
wrote:
> Hello all,
>
> I am playing around w/ Python's object system and decorators and I
> decided to write (as an exercise) a decorator that (if applied to a
> method) would call the superclass' method of the same name
On Jan 12, 7:45 pm, Richard Szopa <[EMAIL PROTECTED]> wrote:
> doing anything (initially I wanted to do something like CLOS
> [1] :before and :end methods, but that turned out to be too
> difficult).
Erm, I meant :before and :after methods.
-- Richard
--
http://mail.python.org/mailman/list
Hello all,
I am playing around w/ Python's object system and decorators and I
decided to write (as an exercise) a decorator that (if applied to a
method) would call the superclass' method of the same name before
doing anything (initially I wanted to do something like CLOS
[1] :before and :end meth
20 matches
Mail list logo
