> On 26/06/2013 9:19 AM, Mark Janssen wrote:
>>
>> Did you ever hear of the Glass Bead Game?
>
> Which was Hesse's condemnation of the
> pure-academic-understanding-unbound-by-pragmatic-use approach as mental
> masturbation,
It was not. He was conflicted. On the one hand he knew the
enterprise w
On 26/06/2013 9:19 AM, Mark Janssen wrote:
Did you ever hear of the Glass Bead Game?
Which was Hesse's condemnation of the
pure-academic-understanding-unbound-by-pragmatic-use approach as mental
masturbation, _not_ a recommendation for how human knowledge should
work. If you think otherwise,
On 06/26/2013 04:54 PM, Steven D'Aprano wrote:
On Wed, 26 Jun 2013 13:14:44 -0700, Ethan Furman wrote:
On 06/23/2013 11:50 AM, Steven D'Aprano wrote:
What else would you call a function that does lookups on the current
object's superclasses?
Well, I would call it super(). Trouble is, that
On Wed, Jun 26, 2013 at 5:54 PM, Steven D'Aprano
wrote:
> No. But "the current object" is not Base1, but an instance of Derived,
> and Base2 *is* an ancestor of Derived. Perhaps if I had said "self"
> instead of current object, you wouldn't have made this error. If so, I
> apologise for confusing
On Wed, 26 Jun 2013 13:14:44 -0700, Ethan Furman wrote:
> On 06/23/2013 11:50 AM, Steven D'Aprano wrote:
>> What else would you call a function that does lookups on the current
>> object's superclasses?
>
> Well, I would call it super(). Trouble is, that is not all that super()
> does. Going b
On 06/23/2013 11:50 AM, Steven D'Aprano wrote:
On Sun, 23 Jun 2013 12:04:35 -0600, Ian Kelly wrote:
On Sun, Jun 23, 2013 at 11:36 AM, Steven D'Aprano
wrote:
On Sun, 23 Jun 2013 11:18:41 -0600, Ian Kelly wrote:
Incidentally, although super() is useful, it's not perfect, and this
is one of my
On 06/23/2013 12:05 PM, Ian Kelly wrote:
On Sun, Jun 23, 2013 at 12:46 PM, Steven D'Aprano
wrote:
All is not lost, there are ways to make your classes cooperative. The
trick is to have your classes' __init__ methods ignore keyword arguments
they don't know what to do with. object used to do the
On Thu, Jun 27, 2013 at 1:16 AM, Rotwang wrote:
> On 25/06/2013 23:57, Chris Angelico wrote:
>>
>> On Wed, Jun 26, 2013 at 8:38 AM, Mark Janssen
>> wrote:
>>>
>>> Combining integers with sets I can make
>>> a Rational class and have infinite-precision arithmetic, for example.
>>
>>
>> Combining t
On 25/06/2013 23:57, Chris Angelico wrote:
On Wed, Jun 26, 2013 at 8:38 AM, Mark Janssen wrote:
Combining integers with sets I can make
a Rational class and have infinite-precision arithmetic, for example.
Combining two integers lets you make a Rational. Python integers are
already infinite-p
Op 26-06-13 00:27, Mark Janssen schreef:
>> The main problem is getting to the top/end of the call chain. Classic
>> example is with __init__, but the same problem can also happen with
>> other calls. Just a crazy theory, but would it be possible to
>> construct a black-holing object that, for any
On Wed, Jun 26, 2013 at 9:19 AM, Mark Janssen wrote:
> Did you ever hear of the Glass Bead Game?
Yeah, it's Magic: The Gathering and its counters.
http://www.wizards.com/magic/magazine/Article.aspx?x=mtgcom/daily/mr195
:)
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, Jun 25, 2013 at 7:07 PM, Mark Janssen wrote:
>> When you inherit a "set" to make a Rational, you're making the
>> statement (to the interpreter, if nothing else) that a Rational is-a
>> set.
>
> No you don't *inherit* a set to make a Rational, although you gain a
> set to make it.
Okay, t
On Tue, 25 Jun 2013 16:19:08 -0700, Mark Janssen wrote:
> Well you've been spoiled by all the work that came before you. The
> issue now is not to go "back to the machine" so much as to tear down and
> build up again from raw materials, objects of more and more complexity
> where very complex "me
On Wed, Jun 26, 2013 at 11:07 AM, Mark Janssen
wrote:
Combining two integers lets you make a Rational.
>>>
>>> Ah, but what is going to group them together? You see you've already
>>> gotten seduced. Python already uses a set to group them together --
>>> it's called a Dict and it's in ever
>>> Combining two integers lets you make a Rational.
>>
>> Ah, but what is going to group them together? You see you've already
>> gotten seduced. Python already uses a set to group them together --
>> it's called a Dict and it's in every Class object.
>
> When you inherit a "set" to make a Ratio
On Tue, Jun 25, 2013 at 5:19 PM, Mark Janssen wrote:
>>> Combining integers with sets I can make
>>> a Rational class and have infinite-precision arithmetic, for example.
>>
>> Combining two integers lets you make a Rational.
>
> Ah, but what is going to group them together? You see you've alread
>> Here's how it *should* be made: the most superest, most badassed
>> object should take care of its children. New instances should
>> automatically call up the super chain (and not leave it up to the
>> subclasses), so that the parent classes can take care of the chil'en.
>> When something goe
>> Combining integers with sets I can make
>> a Rational class and have infinite-precision arithmetic, for example.
>
> Combining two integers lets you make a Rational.
Ah, but what is going to group them together? You see you've already
gotten seduced. Python already uses a set to group them to
On Tue, Jun 25, 2013 at 5:07 PM, Ian Kelly wrote:
> On Tue, Jun 25, 2013 at 4:38 PM, Mark Janssen
> wrote:
>> The issue of classes cooperating isn't as big as it seems, because
>> since you're working now from a useful, agreed-upon common base (the
>> non-negotiable, but also non-arbitrary) mach
On Tue, Jun 25, 2013 at 4:38 PM, Mark Janssen wrote:
> Sorry my last message got sent prematurely. Retrying...
>
>> So instead of super(), you would have sub()? It's an interesting
>> concept, but I don't think it changes anything. You still have to
>> design your classes cooperatively if you e
On Wed, Jun 26, 2013 at 9:00 AM, Mark Janssen wrote:
>> 1) That breaks the Liskov Substitution Principle. A subclass of list
>> ought to fulfill the contracts of a basic list.
>
> We don't need LSP. I write about this on the WIkiWikiWeb where there
> were many arguments documented and many hairs
On Wed, Jun 26, 2013 at 8:38 AM, Mark Janssen wrote:
> Combining integers with sets I can make
> a Rational class and have infinite-precision arithmetic, for example.
Combining two integers lets you make a Rational. Python integers are
already infinite-precision. Or are you actually talking of us
On Wed, Jun 26, 2013 at 8:27 AM, Mark Janssen wrote:
> Here's how it *should* be made: the most superest, most badassed
> object should take care of its children. New instances should
> automatically call up the super chain (and not leave it up to the
> subclasses), so that the parent classes ca
On Wed, Jun 26, 2013 at 8:25 AM, Ian Kelly wrote:
> On Tue, Jun 25, 2013 at 4:17 PM, Chris Angelico wrote:
>> The main problem is getting to the top/end of the call chain. Classic
>> example is with __init__, but the same problem can also happen with
>> other calls. Just a crazy theory, but would
Sorry my last message got sent prematurely. Retrying...
> So instead of super(), you would have sub()? It's an interesting
> concept, but I don't think it changes anything. You still have to
> design your classes cooperatively if you expect to use them with
> multiple inheritance.
Yes, and let
> The main problem is getting to the top/end of the call chain. Classic
> example is with __init__, but the same problem can also happen with
> other calls. Just a crazy theory, but would it be possible to
> construct a black-holing object that, for any given method name,
> returns a dummy function
> So instead of super(), you would have sub()? It's an interesting
> concept, but I don't think it changes anything. You still have to
> design your classes cooperatively if you expect to use them with
> multiple inheritance.
Yes, and let new instances of the child classes automatically ensure
t
On Tue, Jun 25, 2013 at 4:17 PM, Chris Angelico wrote:
> The main problem is getting to the top/end of the call chain. Classic
> example is with __init__, but the same problem can also happen with
> other calls. Just a crazy theory, but would it be possible to
> construct a black-holing object tha
On Tue, Jun 25, 2013 at 3:58 PM, Mark Janssen wrote:
> Ah, and here we see the weakness in the object architecture that has
> evolved in the past decade (not just in Python, note). It hasn't
> really ironed out what end is what. Here's a proposal: the highest,
> most "parental", most general o
On Wed, Jun 26, 2013 at 3:44 AM, Ian Kelly wrote:
> On Sun, Jun 23, 2013 at 1:33 PM, Antoon Pardon
> wrote:
>> Op 23-06-13 18:35, Steven D'Aprano schreef:
>>> Please don't. This is false economy. The time you save will be trivial,
>>> the overhead of inheritance is not going to be the bottleneck
> This bothers me as well. If you look at Raymond Hettinger's "super()
> considered super" article, he includes the (correct) advice that
> super() needs to be used at every level of the call chain. At the end
> of the article, he offers this example to show how "easy" multiple
> inheritance can
On Sun, Jun 23, 2013 at 1:33 PM, Antoon Pardon
wrote:
> Op 23-06-13 18:35, Steven D'Aprano schreef:
>> Please don't. This is false economy. The time you save will be trivial,
>> the overhead of inheritance is not going to be the bottleneck in your
>> code, and by ignoring super, you only accomplis
Op 23-06-13 18:35, Steven D'Aprano schreef:
On Sun, 23 Jun 2013 10:15:38 -0600, Ian Kelly wrote:
If you're worried about efficiency, you can also explicitly name the
superclass in order to call the method directly, like:
A.__init__(self, arg)
Please don't. This is false economy. The
On Mon, 24 Jun 2013 08:58:23 -0700, Mark Janssen wrote:
>>> Mostly I'm saying that super() is badly named.
>>
>> What else would you call a function that does lookups on the current
>> object's superclasses?
>
> ^. You make a symbol for it. ^__init__(foo, bar)
If you want Perl, you can find it
On Mon, Jun 24, 2013 at 9:58 AM, Mark Janssen wrote:
>>> Mostly I'm saying that super() is badly named.
>>
>> What else would you call a function that does lookups on the current
>> object's superclasses?
>
> ^. You make a symbol for it. ^__init__(foo, bar)
On the one hand, eww.
On the other h
On Mon, Jun 24, 2013 at 9:00 AM, Rotwang wrote:
> On 24/06/2013 07:31, Steven D'Aprano wrote:
>
>> I daresay that there are good reasons why new-style classes don't do the
>> same thing, but the point is that had the Python devs had been
>> sufficiently interested in keeping the old behaviour, and
>> Mostly I'm saying that super() is badly named.
>
> What else would you call a function that does lookups on the current
> object's superclasses?
^. You make a symbol for it. ^__init__(foo, bar)
--
MarkJ
Tacoma, Washington
--
http://mail.python.org/mailman/listinfo/python-list
On 24/06/2013 07:31, Steven D'Aprano wrote:
On Mon, 24 Jun 2013 02:53:06 +0100, Rotwang wrote:
On 23/06/2013 18:29, Steven D'Aprano wrote:
On Sat, 22 Jun 2013 23:40:53 -0600, Ian Kelly wrote:
[...]
Can you elaborate or provide a link? I'm curious to know what other
reason there could be for
In article <51c7fe14$0$29973$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> Mixins are such a limited version of MI that it's often not even counted
> as MI, and even when it is, being familiar with mixins is hardly
> sufficient to count yourself as familiar with MI.
OK, fair e
On Sun, 23 Jun 2013 21:38:33 -0400, Roy Smith wrote:
> In article <51c7a087$0$2$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano wrote:
>
>> On Sun, 23 Jun 2013 15:24:14 -0400, Roy Smith wrote:
>>
>> > In article <51c74373$0$2$c3e8da3$54964...@news.astraweb.com>,
>> > Steven D'A
On Mon, 24 Jun 2013 02:53:06 +0100, Rotwang wrote:
> On 23/06/2013 18:29, Steven D'Aprano wrote:
>> On Sat, 22 Jun 2013 23:40:53 -0600, Ian Kelly wrote:
>>> [...]
>>>
>>> Can you elaborate or provide a link? I'm curious to know what other
>>> reason there could be for magic methods to behave diff
On 23/06/2013 18:29, Steven D'Aprano wrote:
On Sat, 22 Jun 2013 23:40:53 -0600, Ian Kelly wrote:
[...]
Can you elaborate or provide a link? I'm curious to know what other
reason there could be for magic methods to behave differently from
normal methods in this regard.
It's an efficiency opti
In article <51c7a087$0$2$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> On Sun, 23 Jun 2013 15:24:14 -0400, Roy Smith wrote:
>
> > In article <51c74373$0$2$c3e8da3$54964...@news.astraweb.com>,
> > Steven D'Aprano wrote:
>
> >> What else would you call a function that
On Sun, 23 Jun 2013 15:24:14 -0400, Roy Smith wrote:
> In article <51c74373$0$2$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano wrote:
>> What else would you call a function that does lookups on the current
>> object's superclasses?
>
> Well, mro_lookup() would have been a better c
On Sun, 23 Jun 2013 13:09:21 -0600, Ian Kelly wrote:
> On Sun, Jun 23, 2013 at 12:50 PM, Steven D'Aprano
> wrote:
>> What else would you call a function that does lookups on the current
>> object's superclasses?
>
> Well, as James Knight points out in the "Super Considered Harmful"
> article, th
On Sunday, June 23, 2013 11:49:42 AM UTC-5, Roy Smith wrote:
> For what it's worth, I never bother to inherit from object
> unless I know there's something I need from new style
> classes. Undoubtedly, this creates a disturbance in The
> Force, but such is life.
Well, in Python 3000, if you don'
On Sunday, June 23, 2013 11:15:38 AM UTC-5, Ian wrote:
> If you're worried about efficiency, you can also
> explicitly name the superclass in order to call the method
> directly, like:
I'm NOT worried about efficiency, i worried about
readability, and using super (when super is NOT absolutely
requ
In article <51c74373$0$2$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> On Sun, 23 Jun 2013 12:04:35 -0600, Ian Kelly wrote:
>
> > On Sun, Jun 23, 2013 at 11:36 AM, Steven D'Aprano
> > wrote:
> >> On Sun, 23 Jun 2013 11:18:41 -0600, Ian Kelly wrote:
> >>
> >>> Incidentally,
On Sun, Jun 23, 2013 at 12:50 PM, Steven D'Aprano
wrote:
> What else would you call a function that does lookups on the current
> object's superclasses?
Well, as James Knight points out in the "Super Considered Harmful"
article, the equivalent in Dylan is called "next-method", which isn't
a valid
On Sun, Jun 23, 2013 at 12:46 PM, Steven D'Aprano
wrote:
> All is not lost, there are ways to make your classes cooperative. The
> trick is to have your classes' __init__ methods ignore keyword arguments
> they don't know what to do with. object used to do the same thing, but it
> no longer does,
On Sun, 23 Jun 2013 12:04:35 -0600, Ian Kelly wrote:
> On Sun, Jun 23, 2013 at 11:36 AM, Steven D'Aprano
> wrote:
>> On Sun, 23 Jun 2013 11:18:41 -0600, Ian Kelly wrote:
>>
>>> Incidentally, although super() is useful, it's not perfect, and this
>>> is one of my grievances with it: that a user ca
On Sun, 23 Jun 2013 12:49:42 -0400, Roy Smith wrote:
> One thing I've never understood about Python 2.x's multiple inheritance
> (mostly because I almost never use it) is how you do something like
> this:
>
> class Base1(object):
>def __init__(self, foo):
> self.foo = foo
>
> class Bas
In article ,
Ian Kelly wrote:
> Yes, you're missing that super() does not simply call the base class,
> but rather the next class in the MRO for whatever the type of the
> "self" argument is. If you write the above as:
>
> class Base1(object):
>def __init__(self, foo, **kwargs):
> su
On Sun, Jun 23, 2013 at 11:36 AM, Steven D'Aprano
wrote:
> On Sun, 23 Jun 2013 11:18:41 -0600, Ian Kelly wrote:
>
>> Incidentally, although super() is useful, it's not perfect, and this is
>> one of my grievances with it: that a user can, based upon the name, draw
>> an inaccurate assumption about
On Sun, 23 Jun 2013 11:18:41 -0600, Ian Kelly wrote:
> Incidentally, although super() is useful, it's not perfect, and this is
> one of my grievances with it: that a user can, based upon the name, draw
> an inaccurate assumption about what it does without reading or fully
> understanding the docum
On Sat, 22 Jun 2013 23:40:53 -0600, Ian Kelly wrote:
> On Sat, Jun 22, 2013 at 11:23 PM, Steven D'Aprano
> wrote:
>> On Sat, 22 Jun 2013 22:27:10 -0600, Ian Kelly wrote:
>>> I actually consider that an up side. Sure it's inconvenient that you
>>> can't delegate all such methods at once just by o
On Sun, Jun 23, 2013 at 11:08 AM, Ian Kelly wrote:
> On Sun, Jun 23, 2013 at 10:49 AM, Roy Smith wrote:
>> am I missing something here?
>
> Yes, you're missing that super() does not simply call the base class,
> but rather the next class in the MRO for whatever the type of the
> "self" argument i
On Sun, Jun 23, 2013 at 10:49 AM, Roy Smith wrote:
> One thing I've never understood about Python 2.x's multiple inheritance
> (mostly because I almost never use it) is how you do something like this:
>
> class Base1(object):
>def __init__(self, foo):
> self.foo = foo
>
> class Base2(obj
In article <51c723b4$0$2$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> On Sun, 23 Jun 2013 10:15:38 -0600, Ian Kelly wrote:
>
> > If you're worried about efficiency, you can also explicitly name the
> > superclass in order to call the method directly, like:
> >
> >
On Sun, 23 Jun 2013 10:15:38 -0600, Ian Kelly wrote:
> If you're worried about efficiency, you can also explicitly name the
> superclass in order to call the method directly, like:
>
> A.__init__(self, arg)
Please don't. This is false economy. The time you save will be trivial,
the over
On Sun, Jun 23, 2013 at 7:35 AM, Adam Jiang wrote:
> Another question raised here is that what is the proper way to refer
> to parent class? For example,
>
> class A(object):
> def __init__(self, arg):
> print "A"
>
> class B(A):
> def __init__(self, arg):
>
> * property only works in "new-style" classes that inherit from object;
>
> * likewise for super;
Another question raised here is that what is the proper way to refer
to parent class? For example,
class A(object):
def __init__(self, arg):
print "A"
class B(A):
d
On Sat, Jun 22, 2013 at 11:23 PM, Steven D'Aprano
wrote:
> On Sat, 22 Jun 2013 22:27:10 -0600, Ian Kelly wrote:
>> I actually consider that an up side. Sure it's inconvenient that you
>> can't delegate all such methods at once just by overriding
>> __getattribute__, but it would be more troubleso
On Sat, 22 Jun 2013 22:27:10 -0600, Ian Kelly wrote:
> On Sat, Jun 22, 2013 at 9:20 PM, Steven D'Aprano
> wrote:
>> * on the down side, automatic delegation of special double-underscore
>> methods like __getitem__ and __str__ doesn't work with new-style
>> classes.
>
> I actually consider that a
On Sat, Jun 22, 2013 at 9:20 PM, Steven D'Aprano
wrote:
> * on the down side, automatic delegation of special double-underscore
> methods like __getitem__ and __str__ doesn't work with new-style classes.
I actually consider that an up side. Sure it's inconvenient that you
can't delegate all such
On Sat, 22 Jun 2013 19:58:38 -0700, Adam wrote:
> class FooBar(object):
> def __init__(self):
> ...
>
> Inheritance usually takes a class name to indicate which class is the
> 'parent' class. However, in the previous example, from a django book,
> the class actually takes an 'object'
class FooBar(object):
def __init__(self):
...
Inheritance usually takes a class name to indicate which class is the 'parent'
class. However, in the previous example, from a django book, the class actually
takes an 'object' like parameter, doesn't it? What is the semantics meaning of
67 matches
Mail list logo
