Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #43601 > unrolled thread

The type/object distinction and possible synthesis of OOP and imperative programming languages

Back to article view | Back to comp.lang.python

Contents

  The type/object distinction and possible synthesis of OOP and imperative programming languages Mark Janssen <dreamingforward@gmail.com> - 2013-04-14 20:48 -0700
    Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-15 10:11 +0000
      Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-04-15 19:43 +0200
        Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-16 02:15 +0000
      Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Dave Angel <davea@davea.name> - 2013-04-15 17:13 -0400
        Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Rotwang <sg552@hotmail.co.uk> - 2013-04-15 23:12 +0100
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Chris Angelico <rosuav@gmail.com> - 2013-04-16 08:32 +1000
            Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Rotwang <sg552@hotmail.co.uk> - 2013-04-15 23:54 +0100
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Mark Janssen <dreamingforward@gmail.com> - 2013-04-16 15:38 -0700
            Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-17 06:40 +0000
              Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Chris Angelico <rosuav@gmail.com> - 2013-04-17 16:56 +1000
              Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Chris Rebert <clp2@rebertia.com> - 2013-04-17 00:16 -0700
              Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-04-17 18:40 -0400
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-16 17:14 -0600
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Michael Torrie <torriem@gmail.com> - 2013-04-18 10:37 -0600
            Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Neil Cerutti <neilc@norwich.edu> - 2013-04-18 17:57 +0000
            Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-19 01:00 +0000
              Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Roy Smith <roy@panix.com> - 2013-04-18 21:08 -0400
                Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Mark Janssen <dreamingforward@gmail.com> - 2013-04-18 18:24 -0700
                Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Ned Batchelder <ned@nedbatchelder.com> - 2013-04-18 22:10 -0400
                Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Mark Janssen <dreamingforward@gmail.com> - 2013-04-18 19:30 -0700
                  Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-19 03:38 +0000
                Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Ned Batchelder <ned@nedbatchelder.com> - 2013-04-18 22:39 -0400
                Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Mark Janssen <dreamingforward@gmail.com> - 2013-05-01 13:32 -0700
                  Re: The type/object distinction and possible synthesis of OOP and imperative programming languages alex23 <wuwei23@gmail.com> - 2013-05-01 18:13 -0700
      Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-15 20:52 -0400
        Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-16 02:32 +0000
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-15 23:17 -0400
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-15 22:46 -0600
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages rusi <rustompmody@gmail.com> - 2013-04-15 21:56 -0700
            Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-16 05:59 +0000
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Serhiy Storchaka <storchaka@gmail.com> - 2013-04-16 11:25 +0300
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-04-16 11:07 +0200
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-16 12:49 -0400
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Ethan Furman <ethan@stoneleaf.us> - 2013-04-16 10:29 -0700
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-16 14:29 -0400
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-16 12:22 -0600
          Re: The type/object distinction and possible synthesis of OOP and imperative programming languages Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-04-17 14:04 +0200
    Re: The type/object distinction and possible synthesis of OOP and imperative programming languages 88888 Dihedral <dihedral88888@googlemail.com> - 2013-04-15 23:54 -0700
    Re: The type/object distinction and possible synthesis of OOP and imperative programming languages 88888 Dihedral <dihedral88888@googlemail.com> - 2013-04-15 23:54 -0700
    Re: The type/object distinction and possible synthesis of OOP and imperative programming languages rusi <rustompmody@gmail.com> - 2013-04-21 08:44 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#43879

On Thu, Apr 18, 2013 at 7:10 PM, Ned Batchelder <ned@nedbatchelder.com> wrote:
> You won't solve the problem of confusing, ambiguous, or conflicting
> terminology by making up a rule.  "Object-oriented" means subtly different
> things to different people.

That's a problem, not a solution.

>  It turns out that computing is a complex field
> with subtle concepts that don't always fit neatly into a categorization.

But that is the point of having a *field*.

> Python, Java, Javascript, Ruby, Smalltalk, Self, PHP, C#, Objective-C, and
> C++ are all "object-oriented", but they also all have differences between
> them.  That's OK.  We aren't going to make up a dozen words as alternatives
> to "object-oriented", one for each language.

Well, you won't, but other people *in the field* already have,
fortunately.  They have names like dynamically-typed,
statically-typed, etc.

> You seem to want to squeeze all of computer science and programming into a
> tidy hierarchy.

No on "squeeze" and "tidy".  Maybe on "hierarchy".

> It won't work, it's not tidy. I strongly suggest you read
> more about computer science before forming more opinions.  You have a lot to
> learn ahead of you.

Okay, professor is it, master?  What is your provenance anyway?

> --Ned.

-- :)



-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#43882

On Thu, 18 Apr 2013 19:30:39 -0700, Mark Janssen wrote:

> On Thu, Apr 18, 2013 at 7:10 PM, Ned Batchelder <ned@nedbatchelder.com>
> wrote:
>> You won't solve the problem of confusing, ambiguous, or conflicting
>> terminology by making up a rule.  "Object-oriented" means subtly
>> different things to different people.
> 
> That's a problem, not a solution.

It's a fact, not necessarily a problem.

"Sandwich" means subtly different things to different people in different 
places, but human beings manage to cope, and very few people accidentally 
eat a sandwich of differently doped silicon crystals (i.e. a transistor) 
when they intended to eat a sandwich of bread and cheese.

So long as people recognise the existence and nature of these subtle 
differences, it's all good. Java's OOP model is different from Python's, 
which is different from Lua's, which is different from Smalltalk's. 
That's all grand, they all have their strengths and weaknesses, and if 
all programming languages were the same, there would only be one. (And it 
would probably be PHP.) 


>>  It turns out that computing is a complex field
>> with subtle concepts that don't always fit neatly into a
>> categorization.
> 
> But that is the point of having a *field*.

Reality is the way it is. However we would like fields of knowledge to 
neatly fit inside pigeonholes, they don't.

 
>> Python, Java, Javascript, Ruby, Smalltalk, Self, PHP, C#, Objective-C,
>> and C++ are all "object-oriented", but they also all have differences
>> between them.  That's OK.  We aren't going to make up a dozen words as
>> alternatives to "object-oriented", one for each language.
> 
> Well, you won't, but other people *in the field* already have,
> fortunately.  They have names like dynamically-typed, statically-typed,
> etc.

They are not names for variations of OOP. They are independent of whether 
a language is OOP or not. For example:


Java is statically typed AND object oriented.
Haskell is statically typed but NOT object oriented.

Python is dynamically typed AND object oriented.
Scheme is dynamically typed but NOT object oriented.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#43880

On 4/18/2013 10:30 PM, Mark Janssen wrote:
> Okay, professor is it, master?  What is your provenance anyway?

I'm not a professor, I'm a software engineer.  I'm just trying to help.  
You've made statements that strike me as half-informed. You're trying to 
unify concepts that perhaps can't or shouldn't be unified.  You've 
posted now to three different mailing lists about your thoughts on the 
nature of programming languages and object-orientation, and have 
apparently had little success in interesting people in them.  A number 
of people have suggested that you study more about the topics you're 
interested in, and I agree with them.

--Ned.

[toc] | [prev] | [next] | [standalone]

#44601

>> Here's a simple rule to resolve the ambiguity.   Whoever publishes
>> first, gets to claim origin of a word and its usage, kind of like a
>> BDFL.  The rest can adapt around that, make up their own word, or be
>> corrected as the community requires.
>
> You seem to want to squeeze all of computer science and programming into a
> tidy hierarchy.  It won't work, it's not tidy. I strongly suggest you read
> more about computer science before forming more opinions.  You have a lot to
> learn ahead of you.

Done:  see the wikiwikiweb:  http://c2.com/cgi/wiki?ComputerScienceVersionTwo
-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#44609

On May 2, 6:32 am, Mark Janssen <dreamingforw...@gmail.com> wrote:
> > You seem to want to squeeze all of computer science and programming into a
> > tidy hierarchy.  It won't work, it's not tidy. I strongly suggest you read
> > more about computer science before forming more opinions.  You have a lot to
> > learn ahead of you.
>
> Done:  see the wikiwikiweb:  http://c2.com/cgi/wiki?ComputerScienceVersionTwo

"There are two camps:
Us, who are right and good.
Them, who are wrong and evil.
Us should be supported, whilst Them should be condemned."

Wow. Just....wow. Because the world really needs a manichean model of
computation.

[toc] | [prev] | [next] | [standalone]

#43651

On 4/15/2013 1:43 PM, Antoon Pardon wrote:

> $ python3
> Python 3.2.3 (default, Feb 20 2013, 17:02:41)
> [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> class vslice (slice):
> ...   pass
> ...
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> TypeError: type 'slice' is not an acceptable base type
>
>
> It seems types and classes are still not mere synonyms.

Some builtin classes cannot be subclassed. There is an issue to document 
which better. That does not mean that it is not a class.

[toc] | [prev] | [next] | [standalone]

#43655

On Mon, 15 Apr 2013 20:52:58 -0400, Terry Jan Reedy wrote:

> On 4/15/2013 1:43 PM, Antoon Pardon wrote:
> 
>> $ python3
>> Python 3.2.3 (default, Feb 20 2013, 17:02:41) [GCC 4.7.2] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>  >>> class vslice (slice):
>> ...   pass
>> ...
>> Traceback (most recent call last):
>>    File "<stdin>", line 1, in <module>
>> TypeError: type 'slice' is not an acceptable base type
>>
>>
>> It seems types and classes are still not mere synonyms.
> 
> Some builtin classes cannot be subclassed. There is an issue to document
> which better. That does not mean that it is not a class.


I think it is also important to document whether that is a language 
feature, or a mere restriction of the implementation. There is an 
important distinction to be made between:

"In CPython, you cannot subclass slice or FunctionType. Other Pythons may 
have more, or fewer, restrictions."

and:

"No language that calls itself Python is permitted to allow slice and 
FunctionType to be subclassable."


If I had a say in this, I would vote for the first case, with the 
possible exception of documented singleton types like NoneType and bool.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#43658

On 4/15/2013 10:32 PM, Steven D'Aprano wrote:
> On Mon, 15 Apr 2013 20:52:58 -0400, Terry Jan Reedy wrote:

>> Some builtin classes cannot be subclassed. There is an issue to document
>> which better. That does not mean that it is not a class.
>
>
> I think it is also important to document whether that is a language
> feature, or a mere restriction of the implementation. There is an
> important distinction to be made between:
>
> "In CPython, you cannot subclass slice or FunctionType. Other Pythons may
> have more, or fewer, restrictions."
>
> and:
>
> "No language that calls itself Python is permitted to allow slice and
> FunctionType to be subclassable."
>
>
> If I had a say in this, I would vote for the first case, with the
> possible exception of documented singleton types like NoneType and bool.

I will keep the above in mind if I write or review a patch. here are 4 
non-subclassable builtin classes. Two are already documented. Bool in 
one, forget which other. I believe it was recently decided to leave the 
other two as is given the absence of any practical use case.

[toc] | [prev] | [next] | [standalone]

#43659

On Mon, Apr 15, 2013 at 9:17 PM, Terry Jan Reedy <tjreedy@udel.edu> wrote:
> I will keep the above in mind if I write or review a patch. here are 4
> non-subclassable builtin classes. Two are already documented. Bool in one,
> forget which other. I believe it was recently decided to leave the other two
> as is given the absence of any practical use case.

The four are bool, NoneType, slice and ellipsis, I believe.

[toc] | [prev] | [next] | [standalone]

#43660

On Apr 16, 7:32 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
>
> If I had a say in this, I would vote for the first case, with the
> possible exception of documented singleton types like NoneType and bool.

How is bool a singleton type?

[toc] | [prev] | [next] | [standalone]

#43661

On Mon, 15 Apr 2013 21:56:12 -0700, rusi wrote:

> On Apr 16, 7:32 am, Steven D'Aprano <steve
> +comp.lang.pyt...@pearwood.info> wrote:
>>
>> If I had a say in this, I would vote for the first case, with the
>> possible exception of documented singleton types like NoneType and
>> bool.
> 
> How is bool a singleton type?


A doubleton, then.


The point being, GvR declared that bool should guarantee the invariant 
that True and False are the only instances of bool, and if you can 
subclass it, either that invariant is violated, or you can't instantiate 
the subclass.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#43664

On 16.04.13 07:46, Ian Kelly wrote:
> On Mon, Apr 15, 2013 at 9:17 PM, Terry Jan Reedy <tjreedy@udel.edu> wrote:
>> I will keep the above in mind if I write or review a patch. here are 4
>> non-subclassable builtin classes. Two are already documented. Bool in one,
>> forget which other. I believe it was recently decided to leave the other two
>> as is given the absence of any practical use case.
>
> The four are bool, NoneType, slice and ellipsis, I believe.

 >>> import builtins
 >>> for n in dir(builtins):
...     if type(getattr(builtins, n)) is type:
...         try:
...             t = type(n, (getattr(builtins, n),), {})
...         except TypeError as e:
...             print(e)
...
type 'bool' is not an acceptable base type
type 'memoryview' is not an acceptable base type
type 'range' is not an acceptable base type
type 'slice' is not an acceptable base type

[toc] | [prev] | [next] | [standalone]

#43665

Op 16-04-13 05:17, Terry Jan Reedy schreef:
> On 4/15/2013 10:32 PM, Steven D'Aprano wrote:
>> On Mon, 15 Apr 2013 20:52:58 -0400, Terry Jan Reedy wrote:
>
>>> Some builtin classes cannot be subclassed. There is an issue to
>>> document
>>> which better. That does not mean that it is not a class.
>>
>>
>> I think it is also important to document whether that is a language
>> feature, or a mere restriction of the implementation. There is an
>> important distinction to be made between:
>>
>> "In CPython, you cannot subclass slice or FunctionType. Other Pythons
>> may
>> have more, or fewer, restrictions."
>>
>> and:
>>
>> "No language that calls itself Python is permitted to allow slice and
>> FunctionType to be subclassable."
>>
>>
>> If I had a say in this, I would vote for the first case, with the
>> possible exception of documented singleton types like NoneType and bool.
>
> I will keep the above in mind if I write or review a patch. here are 4
> non-subclassable builtin classes. Two are already documented. Bool in
> one, forget which other. I believe it was recently decided to leave
> the other two as is given the absence of any practical use case.

Why should there be a practical use case here? Since classes are in
general subclassable, shouldn't you have a reason to not make them so
instead of people needing to give you a practical use case before you
treat them as you do most of them?

I once had an idea of a slice-like class that I would have liked to
experiment with. As things were I didn't get far because slice not being
subclassable was a major hurdle in getting it practical. Would the end
result have been a practical use case? I don't know, I didn't get the
chance to find out because making a class that looked like a slice
didn't work either. Python wanted, maybe still wants, a real slice in a
number of circumstances and not a ducktyped slice-like object.

Now maybe there are good reasons for slice not being subclassable but
there not being a practical use case doesn't seem to be one in this case.

[toc] | [prev] | [next] | [standalone]

#43683

On 4/16/2013 5:07 AM, Antoon Pardon wrote:
> Op 16-04-13 05:17, Terry Jan Reedy schreef:
>> On 4/15/2013 10:32 PM, Steven D'Aprano wrote:
>>> On Mon, 15 Apr 2013 20:52:58 -0400, Terry Jan Reedy wrote:
>>

>> I will keep the above in mind if I write or review a patch. here are 4
>> non-subclassable builtin classes. Two are already documented. Bool in
>> one, forget which other. I believe it was recently decided to leave
>> the other two as is given the absence of any practical use case.
>
> Why should there be a practical use case here?

As a practical matter, the change is non-trivial. Someone has to be 
motivated to write the patch to enable subclassing, write tests, and 
consider the effect on internal C uses of slice and stdlib Python used 
of slice (type() versus isinstance).

> Since classes are in general subclassable,

if written in Python, but not if written in C.

> I once had an idea of a slice-like class that I would have liked to
> experiment with.

Did the idea actually require that instances *be* a slice rather than 
*wrap* a slice?

--
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#43693

On 04/16/2013 01:25 AM, Serhiy Storchaka wrote:
> On 16.04.13 07:46, Ian Kelly wrote:
>> On Mon, Apr 15, 2013 at 9:17 PM, Terry Jan Reedy <tjreedy@udel.edu> wrote:
>>> I will keep the above in mind if I write or review a patch. here are 4
>>> non-subclassable builtin classes. Two are already documented. Bool in one,
>>> forget which other. I believe it was recently decided to leave the other two
>>> as is given the absence of any practical use case.
>>
>> The four are bool, NoneType, slice and ellipsis, I believe.
>
> --> import builtins
> --> for n in dir(builtins):
> ...     if type(getattr(builtins, n)) is type:
> ...         try:
> ...             t = type(n, (getattr(builtins, n),), {})
> ...         except TypeError as e:
> ...             print(e)
> ...
> type 'bool' is not an acceptable base type
> type 'memoryview' is not an acceptable base type
> type 'range' is not an acceptable base type
> type 'slice' is not an acceptable base type

Well that bumps our count to five then:

--> NoneType = type(None)
--> NoneType
<class 'NoneType'>
--> class MoreNone(NoneType):
...   pass
...
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
TypeError: type 'NoneType' is not an acceptable base type

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#43696

On 4/16/2013 1:29 PM, Ethan Furman wrote:
> On 04/16/2013 01:25 AM, Serhiy Storchaka wrote:
>> On 16.04.13 07:46, Ian Kelly wrote:
>>> On Mon, Apr 15, 2013 at 9:17 PM, Terry Jan Reedy <tjreedy@udel.edu>
>>> wrote:
>>>> I will keep the above in mind if I write or review a patch. here are 4
>>>> non-subclassable builtin classes. Two are already documented. Bool
>>>> in one,
>>>> forget which other. I believe it was recently decided to leave the
>>>> other two
>>>> as is given the absence of any practical use case.
>>>
>>> The four are bool, NoneType, slice and ellipsis, I believe.
>>
>> --> import builtins
>> --> for n in dir(builtins):
>> ...     if type(getattr(builtins, n)) is type:
>> ...         try:
>> ...             t = type(n, (getattr(builtins, n),), {})
>> ...         except TypeError as e:
>> ...             print(e)
>> ...
>> type 'bool' is not an acceptable base type
>> type 'memoryview' is not an acceptable base type
>> type 'range' is not an acceptable base type
>> type 'slice' is not an acceptable base type
>
> Well that bumps our count to five then:
>
> --> NoneType = type(None)
> --> NoneType
> <class 'NoneType'>
> --> class MoreNone(NoneType):
> ...   pass
> ...
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
> TypeError: type 'NoneType' is not an acceptable base type

'NoneType' is not a builtin name in builtins, which is precisely why you 
accessed it the way you did ;-). From issue 17279 (for 3.3):

"Attached subclassable.py produces these lists:
Among named builtin classes, these cannot be subclassed:
bool, memoryview, range, slice,
Among types classes, these can be subclassed:
ModuleType, SimpleNamespace,"

[toc] | [prev] | [next] | [standalone]

#43697

On Tue, Apr 16, 2013 at 11:29 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
>>> The four are bool, NoneType, slice and ellipsis, I believe.
>>
>>
>> --> import builtins
>> --> for n in dir(builtins):
>>
>> ...     if type(getattr(builtins, n)) is type:
>> ...         try:
>> ...             t = type(n, (getattr(builtins, n),), {})
>> ...         except TypeError as e:
>> ...             print(e)
>> ...
>> type 'bool' is not an acceptable base type
>> type 'memoryview' is not an acceptable base type
>> type 'range' is not an acceptable base type
>> type 'slice' is not an acceptable base type
>
>
> Well that bumps our count to five then:

Six.

>>> class test(type(...)): pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type 'ellipsis' is not an acceptable base type

[toc] | [prev] | [next] | [standalone]

#43757

Op 16-04-13 18:49, Terry Jan Reedy schreef:
> On 4/16/2013 5:07 AM, Antoon Pardon wrote:
>> Op 16-04-13 05:17, Terry Jan Reedy schreef:
>>
>>> I will keep the above in mind if I write or review a patch. here are 4
>>> non-subclassable builtin classes. Two are already documented. Bool in
>>> one, forget which other. I believe it was recently decided to leave
>>> the other two as is given the absence of any practical use case.
>>
>> Why should there be a practical use case here?
>
> As a practical matter, the change is non-trivial. Someone has to be
> motivated to write the patch to enable subclassing, write tests, and
> consider the effect on internal C uses of slice and stdlib Python used
> of slice (type() versus isinstance).
I see. It seems I have underestimated the work involved.

>> I once had an idea of a slice-like class that I would have liked to
>> experiment with.
>
> Did the idea actually require that instances *be* a slice rather than
> *wrap* a slice? 

As far as I remember I wanted my slice object usable to slice lists
with. But python doesn't allow duck typing when you use your object to
"index" a list. No matter how much your object resembles a slice, when
you actualy try to use it to get a slice of a list, python throw a
TypeError with the message "object cannot be interpreted as an index".
This in combination with slice not being subclassable effectively killed
the idea.

As I already said I don't know if the idea would have turned up
something usefull. The following years I never had the feeling how great
it would have been should I have been able to pursue this idea. I just
thought it was a pity I was so thoroughly stopped at the time.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#43662

zipher於 2013年4月15日星期一UTC+8上午11時48分05秒寫道：
> Hello,
> 
> 
> 
> I'm new to the list and hoping this might be the right place to
> 
> introduce something that has provoked a bit of an argument in my
> 
> programming community.

I'll state about my opinions about the imperative and 
non-imperative part.

If the finite stack depth is used instead of the infinite one,
then the auto local variables of the imperative part 
can be implemented quite safe  and cheap or at least 
self-recoverable from a stack overflow event.

This can save a lot burdens in the GC part in an imperative 
language.
 

[toc] | [prev] | [next] | [standalone]

#43663

zipher於 2013年4月15日星期一UTC+8上午11時48分05秒寫道：
> Hello,
> 
> 
> 
> I'm new to the list and hoping this might be the right place to
> 
> introduce something that has provoked a bit of an argument in my
> 
> programming community.

I'll state about my opinions about the imperative and 
non-imperative part.

If the finite stack depth is used instead of the infinite one,
then the auto local variables of the imperative part 
can be implemented quite safe  and cheap or at least 
self-recoverable from a stack overflow event.

This can save a lot burdens in the GC part in an imperative 
language.
 

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web