there is more than one implementation of
interfaces, support for testing them cannot be at the keyword
level and remains through functions and methods. This is actually
pretty easy to use, though.
Giving isinstance() a keyword status as "isa" would encourage
bad style, though, as it would at
Colin J. Williams wrote:
> Could you elaborate on that please?
See my earlier post in this thread, this link:
http://www.canonical.org/~kragen/isinstance/
--
http://mail.python.org/mailman/listinfo/python-list
Colin J. Williams wrote:
> Rocco Moretti wrote:
>
>> Terry Hancock wrote:
>>
>>> On Thursday 01 September 2005 07:28 am, Fuzzyman wrote:
>>>
What's the difference between this and ``isinstance`` ?
>>>
>>> I must confess that an "isa" operator sounds like it would
>>> have been slightly nicer
Rocco Moretti wrote:
> Terry Hancock wrote:
>
>> On Thursday 01 September 2005 07:28 am, Fuzzyman wrote:
>>
>>> What's the difference between this and ``isinstance`` ?
>>
>>
>> I must confess that an "isa" operator sounds like it would
>> have been slightly nicer syntax than the isinstance() built
phil hunt wrote:
> On Sat, 03 Sep 2005 00:45:19 -0500, Steve Holden <[EMAIL PROTECTED]> wrote:
>
>>>I'm not talking about a change in *paradigm* merely a change in
>>>*syntax*; this:
>>>
>>> receiver selector argument
>>>
>>>would mean the same as the current Python:
>>>
>>> receiver.selector
On Sat, 03 Sep 2005 00:45:19 -0500, Steve Holden <[EMAIL PROTECTED]> wrote:
>> I'm not talking about a change in *paradigm* merely a change in
>> *syntax*; this:
>>
>>receiver selector argument
>>
>> would mean the same as the current Python:
>>
>>receiver.selector(argument)
>>
>Aah, I
container types.
Your analogy doesn't apply to non dictionaries. In any case, nothing
stops you from writing your own has_key() method for a different
container type. Likewise, if you made an isa keyword, it would just
call a method to have the traits you described above. You could write
your
On Thu, 01 Sep 2005 21:25:20 -0500, D H <[EMAIL PROTECTED]> wrote:
>talin at acm dot org wrote:
>> Although I realize the perils of even suggesting polluting the Python
>> namespace with a new keyword, I often think that it would be useful to
>> consider defining an operator for testing whether or
phil hunt wrote:
> On Thu, 01 Sep 2005 20:39:14 -0500, Steve Holden <[EMAIL PROTECTED]> wrote:
>
>>phil hunt wrote:
>>
>>>It could be argued of course, that an OOPL should allow methods to
>>>be sent with a grammar:
>>>
>>> receiver selector argument
>>>
>>>(which is almost what Smalltalk does)
On Thu, 01 Sep 2005 20:39:14 -0500, Steve Holden <[EMAIL PROTECTED]> wrote:
>phil hunt wrote:
>> It could be argued of course, that an OOPL should allow methods to
>> be sent with a grammar:
>>
>>receiver selector argument
>>
>> (which is almost what Smalltalk does), but you're not arguing f
Thanks for all the respones :) I realized up front that this suggestion
is unlikely to gain approval, for reasons eloquently stated above.
However, there are still some interesting issues raised that I would
like to discuss.
Let me first respond to a few of the comments:
>What's the difference be
Terry Hancock wrote:
> On Thursday 01 September 2005 07:28 am, Fuzzyman wrote:
>
>>What's the difference between this and ``isinstance`` ?
>
> I must confess that an "isa" operator sounds like it would
> have been slightly nicer syntax than the isinstance() built-in
> function. But not enough nic
On Thursday 01 September 2005 07:28 am, Fuzzyman wrote:
> On 1 Sep 2005 00:52:54 -0700, "talin at acm dot org"
> <[EMAIL PROTECTED]> wrote:
> What's the difference between this and ``isinstance`` ?
Other than proposing a keyword operator instead of a function,
apparently nothing.
isinstance() ev
talin at acm dot org wrote:
> Although I realize the perils of even suggesting polluting the Python
> namespace with a new keyword, I often think that it would be useful to
> consider defining an operator for testing whether or not an item is a
> member of a category.
It's a good idea but not like
phil hunt wrote:
> On 1 Sep 2005 00:52:54 -0700, talin at acm dot org <[EMAIL PROTECTED]> wrote:
>
>>The "isa" operator would of course be overloadable, perhaps by an
>>accessor functions called __isa__, which works similarly to
>>__contains__. The potential uses for this are not limited to
>>isin
On 1 Sep 2005 00:52:54 -0700, talin at acm dot org <[EMAIL PROTECTED]> wrote:
>
>The "isa" operator would of course be overloadable, perhaps by an
>accessor functions called __isa__, which works similarly to
>__contains__. The potential uses for this are not limited to
>isinstance() sugar, however.
On 1 Sep 2005 00:52:54 -0700, "talin at acm dot org"
<[EMAIL PROTECTED]> wrote:
>Although I realize the perils of even suggesting polluting the Python
>namespace with a new keyword, I often think that it would be useful to
>consider defining an operator for testing whether or not an item is a
>mem
"talin at acm dot org" <[EMAIL PROTECTED]> writes:
> membership within a container -- instead we're testing for membership
> with a type hierarchy, where 'type' can be defined to mean whatever the
> programmer wants.
Well, if "type" means a (possibly infinite) set of objects, then you
can use "in"
Although I realize the perils of even suggesting polluting the Python
namespace with a new keyword, I often think that it would be useful to
consider defining an operator for testing whether or not an item is a
member of a category.
Currently, we have the 'in' operator, which tests for membership
19 matches
Mail list logo