Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
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. Justwow. Because the world really needs a manichean model of computation. -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Apr 15, 8:48 am, Mark Janssen dreamingforw...@gmail.com wrote: That all being said, the thrust of this whole effort is to possibly advance Computer Science and language design, because in-between the purely concrete object architecture of the imperative programming languages and the purely abstract object architecture of object-oriented programming languages is a possible middle ground that could unite them all. Just been poking around with eclipse. And saw this: http://softwaresimplexity.blogspot.in/2013/02/where-java-fails.html For context, the guy seems to be big in the java/eclipse community [Or at least is well hyped -- he's finalist for eclipse' best developer award] This context is needed to underscore something he says in one of the comments on that page: OO just sucks… -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Fri, Apr 19, 2013 at 1:35 PM, rusi rustompm...@gmail.com wrote: If I have a loop: while i len(a) and a[i] != x: i++ I need to understand that at the end of the loop: i = len(a) or a[i] == x and not i = len(a) and a[i] == x nor i == len(a) or a[i] == x # What if I forgot to initialize i? Or your program has crashed out with an exception. i,a,x=-10,test,q while i len(a) and a[i] != x: i+=1 Traceback (most recent call last): File pyshell#69, line 1, in module while i len(a) and a[i] != x: IndexError: string index out of range Or if that had been in C, it could have bombed with a segfault rather than a nice tidy exception. Definitely initialize i. But yeah, the basis of algebra is helpful, even critical, to understanding most expression evaluators. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On 04/16/2013 04:38 PM, Mark Janssen wrote: (Note this contrasts starkly with Java(script), which doesn't seem to be based on anything -- can anyone clarify where Java actually comes from?) Java is not equal in any way with JavaScript. The only thing they share are semicolons and braces. Naming EMCAScript JavaScript was a very unfortunate thing indeed. For the record, JavaScript is what they call a prototype-based language. http://en.wikipedia.org/wiki/Prototype-based_programming. You can emulate an OOP system with a prototype-based language. I highly recommend you read a book on formal programming language theory and concepts. -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On 2013-04-18, Michael Torrie torr...@gmail.com wrote: On 04/16/2013 04:38 PM, Mark Janssen wrote: (Note this contrasts starkly with Java(script), which doesn't seem to be based on anything -- can anyone clarify where Java actually comes from?) Java is not equal in any way with JavaScript. The only thing they share are semicolons and braces. Naming EMCAScript JavaScript was a very unfortunate thing indeed. For the record, JavaScript is what they call a prototype-based language. http://en.wikipedia.org/wiki/Prototype-based_programming. You can emulate an OOP system with a prototype-based language. I highly recommend you read a book on formal programming language theory and concepts. Let me recommend Concepts, Techniques and Models of Computer Programming, Van Roy and Haridi. http://www.info.ucl.ac.be/~pvr/book.html -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Thu, 18 Apr 2013 10:37:17 -0600, Michael Torrie wrote: For the record, JavaScript is what they call a prototype-based language. http://en.wikipedia.org/wiki/Prototype-based_programming. You can emulate an OOP system with a prototype-based language. Prototype languages *are* OOP. Note that it is called OBJECT oriented programming, not class oriented, and prototype-based languages are based on objects just as much as class-based languages. They are merely two distinct models for OOP. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
In article 51709740$0$29977$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Thu, 18 Apr 2013 10:37:17 -0600, Michael Torrie wrote: For the record, JavaScript is what they call a prototype-based language. http://en.wikipedia.org/wiki/Prototype-based_programming. You can emulate an OOP system with a prototype-based language. Prototype languages *are* OOP. Note that it is called OBJECT oriented programming, not class oriented, and prototype-based languages are based on objects just as much as class-based languages. They are merely two distinct models for OOP. One of the nice things about OOP is it means so many different things to different people. All of whom believe with religious fervor that they know the true answer. -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
One of the nice things about OOP is it means so many different things to different people. All of whom believe with religious fervor that they know the true answer. 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. -- MarkJ Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On 4/18/2013 9:24 PM, Mark Janssen wrote: One of the nice things about OOP is it means so many different things to different people. All of whom believe with religious fervor that they know the true answer. 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 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. It turns out that computing is a complex field with subtle concepts that don't always fit neatly into a categorization. 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. 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. --Ned. -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Thu, Apr 18, 2013 at 7:10 PM, Ned Batchelder n...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Thu, 18 Apr 2013 19:30:39 -0700, Mark Janssen wrote: On Thu, Apr 18, 2013 at 7:10 PM, Ned Batchelder n...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Apr 19, 3:53 am, Mark Janssen dreamingforw...@gmail.com wrote: On Mon, Apr 15, 2013 at 2:53 AM, Moez AbdelGawad moeza...@outlook.com wrote: I'm not quite sure I understand your question, but I'll give it a shot. :-) I'm in this same camp too :) I am very thankful for the references given by everyone. Unfortunately my library does not have the titles and it will be some time before I can acquire them. I hope it not too intrusive to offer a few points that I've garnered from this conversation until I can study the history further. You may want to see this: http://www.infoq.com/presentations/Functional-Thinking The main thing that I notice is that there is a heavy bias in academia towards mathematical models. Yeah wonderful observation. Lets clean up! If I have a loop: while i len(a) and a[i] != x: i++ I need to understand that at the end of the loop: i = len(a) or a[i] == x and not i = len(a) and a[i] == x nor i == len(a) or a[i] == x # What if I forgot to initialize i? Now why bother to teach students such a silly thing (and silly name) as deMorgan? So all hail to your project of cleaning up the useless math from CS. And to whet your appetite for the grandeur and glory of your visionings why not start with making music schools enroll tone-deaf students? Why wasn't Beethoven deaf? I understand that Turing Machines, for example, were originally abstract computational concepts before there was an implementation in hardware, so I have some sympathies with that view, yet, should not the Science of Computer Science concern itself with how to map these abstract computational concepts into actual computational hardware? Otherwise, why not keep the field within mathematics and philosophy (where Logic traditionally has been)? I find it remarkable, for example, that the simple continued application of And/Or/Not gates can perform all the computation that C.S. concerns itself with and these form the basis for computer science in my mind, along with Boolean logic. (The implementation of digital logic into physical hardware is where C.S. stops and Engineering begins, I would argue.) You need to study some history (or is that irrelevant like math?) The Turing who invented the Turing machine in 1936 led the code- cracking efforts of the allies a couple of years later. Do you allow for the fact that he may have had abilities that were common to both aka 'math' 'theory' etc? Or do you believe that winning wars is a theoretical and irrelevant exercise? But still, it seems that there are two ends, two poles, to the whole computer science enterprise that haven't been sufficiently *separated* so that they can be appreciated: logic gates vs. logical calculus and symbols. There is very little crossover as I can see. Perhaps the problem is the common use of the Greek root logikos; in the former, it pertains to binary arithmetic, where in the latter, it retains it's original Greek pertaining to *speech* and symbols, logos). Yes there is some truth in what you say. Just call it logic as object- language (what you call logic-gates) and logic as meta-language ie logic for reasoning [the above line is not sarcastic] Further, one can notice that in the former, the progression has been towards more sophisticated Data Structures (hence the evolution towards Object-Orientation), where in the latter (I'm guessing, since it's not my area of expertise) the progression has been towards function sophistication (where recursion seems to be paramount). Also good to study the views of one of the doyens of OOP: http://en.wikipedia.org/wiki/Alexander_Stepanov#Criticism_of_OOP -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
The main thing that I notice is that there is a heavy bias in academia towards mathematical models. Yeah wonderful observation. Lets clean up! If I have a loop: while i len(a) and a[i] != x: i++ I need to understand that at the end of the loop: i = len(a) or a[i] == x and not i = len(a) and a[i] == x nor i == len(a) or a[i] == x # What if I forgot to initialize i? You know in my world, we have what's called Input/Output, rather than punchcards or switchbanks where you come from. Why not: print i,a[i]. Done! Now why bother to teach students such a silly thing (and silly name) as deMorgan? Well deMorgan falls into BooleanLogic which I'm arguing is distinct from the the mathematical realm where the lambda calculus wizards come from. So that's my camp, thanks. So all hail to your project of cleaning up the useless math from CS. Yes, on useless math, no on *useful* math. Thanks. And to whet your appetite for the grandeur and glory of your visionings why not start with making music schools enroll tone-deaf students? Why wasn't Beethoven deaf? Beethoven was deaf. You need to study some history (or is that irrelevant like math?) The Turing who invented the Turing machine in 1936 led the code- cracking efforts of the allies a couple of years later. Do you allow for the fact that he may have had abilities that were common to both aka 'math' 'theory' etc? Or do you believe that winning wars is a theoretical and irrelevant exercise? Please, I don't dismiss math anymore than a number theorist might dismiss the realm of complex numbers. Yes there is some truth in what you say. Just call it logic as object- language (what you call logic-gates) and logic as meta-language ie logic for reasoning Right, and I'm arguing that there hasn't been enough conceptual separation between the two. So why are you arguing? Also good to study the views of one of the doyens of OOP: http://en.wikipedia.org/wiki/Alexander_Stepanov#Criticism_of_OOP That's a very good reference. It voices some of my points that are in criticism of python's object architecture. -- MarkJ Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Tue, 16 Apr 2013 15:38:29 -0700, Mark Janssen wrote: On Mon, Apr 15, 2013 at 3:32 PM, Chris Angelico ros...@gmail.com wrote: On Tue, Apr 16, 2013 at 8:12 AM, Rotwang sg...@hotmail.co.uk wrote: Traceback (most recent call last): File pyshell#2, line 1, in module class C(type(lambda: None)): TypeError: type 'function' is not an acceptable base type and I don't think that FunctionType would be considered an internal detail, would it? Not that I'd cite the fact that not all types can be inherited from as evidence that types and classes are not synonyms, mind. Actually, I'm not sure how you'd go about inheriting from a function. Why not just create a bare class, then assign its __call__ to be the function you're inheriting from? I think his point remains valid, from a theoretical pov. Python prides itself on the idea of first-class functions and such, but unlike the world of lambda calculus, this selling point is a bit invalid. Python functions are first-class functions, which is short-hand for saying functions which are also capable of being treated as values, which means they can be created at run-time, returned from functions, passed around as arguments, and assigned to variables. Python's function type is not a first-class object-type, because it cannot be subclassed in at least three of the main implementations. But this has nothing to do with whether or not functions are first-class functions, which is an unrelated meaning. One can conceive of a language where FunctionType is a first-class type capable of being subclasses, but functions are *not* first-class values capable of being passed around as arguments. Because for Python (and any C-based language), Python-the-language is not C-based, or at least, very little of Python is C-based. It's main influences are, according to GvR, Lisp and ABC, with Pascal, Haskell and of course C also having some influence. Syntax-wise, it is much more of an Algol-inspired language than a C-inspired language. it is roots squarely in the Turing machine and its real-word implementation. Python is certainly not inspired by Turing machines. Since a Turing machine is a simple device with an infinitely long paper tape which can have marks added and deleted from it, very few real programming languages are based on Turing machines. It is, however, Turing-complete. Just like every programming language worthy of the name, whether it has syntax like Python, C, Lisp, Forth, INTERCAL, Oook, Applescript, Inform-7, Java, PHP, or x86 assembler. (Note this contrasts starkly with Java(script), which doesn't seem to be based on anything -- can anyone clarify where Java actually comes from?) C. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Wed, Apr 17, 2013 at 4:40 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 16 Apr 2013 15:38:29 -0700, Mark Janssen wrote: (Note this contrasts starkly with Java(script), which doesn't seem to be based on anything -- can anyone clarify where Java actually comes from?) C. offee. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Tue, Apr 16, 2013 at 11:40 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 16 Apr 2013 15:38:29 -0700, Mark Janssen wrote: snip (Note this contrasts starkly with Java(script), which doesn't seem to be based on anything -- can anyone clarify where Java actually comes from?) C. Influenced by: Ada 83, C++, C#, Eiffel, Generic Java, Mesa, Modula-3, Oberon, Objective-C, UCSD Pascal, Smalltalk Categories: C programming language family | [...] – http://en.wikipedia.org/wiki/Java_(programming_language) Sincerely, Chris -- Read Wikipedia's infoboxes! People work hard on them! -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On 16.04.13 07:46, Ian Kelly wrote:
On Mon, Apr 15, 2013 at 9:17 PM, Terry Jan Reedy tjre...@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
--
http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
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 tjre...@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~
--
http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
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 tjre...@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,
--
http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Tue, Apr 16, 2013 at 11:29 AM, Ethan Furman et...@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
--
http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Mon, Apr 15, 2013 at 3:32 PM, Chris Angelico ros...@gmail.com wrote: On Tue, Apr 16, 2013 at 8:12 AM, Rotwang sg...@hotmail.co.uk wrote: Traceback (most recent call last): File pyshell#2, line 1, in module class C(type(lambda: None)): TypeError: type 'function' is not an acceptable base type and I don't think that FunctionType would be considered an internal detail, would it? Not that I'd cite the fact that not all types can be inherited from as evidence that types and classes are not synonyms, mind. Actually, I'm not sure how you'd go about inheriting from a function. Why not just create a bare class, then assign its __call__ to be the function you're inheriting from? I think his point remains valid, from a theoretical pov. Python prides itself on the idea of first-class functions and such, but unlike the world of lambda calculus, this selling point is a bit invalid. Because for Python (and any C-based language), it is roots squarely in the Turing machine and its real-word implementation. (Note this contrasts starkly with Java(script), which doesn't seem to be based on anything -- can anyone clarify where Java actually comes from?) -- MarkJ Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Tue, Apr 16, 2013 at 4:38 PM, Mark Janssen dreamingforw...@gmail.com wrote: I think his point remains valid, from a theoretical pov. Python prides itself on the idea of first-class functions and such, but unlike the world of lambda calculus, this selling point is a bit invalid. Because for Python (and any C-based language), it is roots squarely in the Turing machine and its real-word implementation. I'm having a hard time following what you're trying to say here. Lambda calculus and Turing machines are theoretical models of computation, not languages. You can model Lisp programs with Turing machine, and you can model C programs with lambda expressions. Practically speaking you would probably have an easier time doing it the other way around, due to the procedural nature of the Turing machine versus the functional nature of the lambda calculus. By the usual definition of first-class function [1], Python functions are first-class; this has nothing to do with functional vs. procedural programming (although it is more commonly found in the former) or to do with Turing machines (which don't even include functions as a concept). (Note this contrasts starkly with Java(script), which doesn't seem to be based on anything -- can anyone clarify where Java actually comes from?) I don't understand why you would consider Python to be C-based or Turing machine-based but not Java or Javascript. [1] http://en.wikipedia.org/wiki/First-class_citizen -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Sun, 14 Apr 2013 20:48:05 -0700, Mark Janssen wrote: 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'm from the Python programming community. Python is an interpreted language. Since 2001, Python's has migrated towards a pure Object model (ref: http://www.python.org/download/releases/2.2/descrintro/). Prior to then, it had both types and classes and these types were anchored to the underlying C code and the machine/hardware architecture itself. Incorrect. Python's data model has always been 100% object oriented. Prior to the class/type unification, it simply had *two distinct* implementations of objects: types, which were written in C, and classes, which were written in Python. After unification, the two kinds of object were no longer entirely distinct -- you could then subclass types in Python code, using the same class keyword as you would use for a pure-Python class. And starting with Python 3, the last vestiges of the distinction have disappeared. Now, class and type are mere synonyms. Both built-in types and custom classes use the same mechanism. After the 2001 type/class unification , it went towards Alan Kay's ideal of everything is an object. From then, every user-defined class inherited from the abstract Object, rooted in nothing but a pure abstract ideal. Incorrect. In Python 2.7: py class AClass: ... pass ... py issubclass(AClass, object) False -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
Op 15-04-13 12:11, Steven D'Aprano schreef: Python's data model has always been 100% object oriented. Prior to the class/type unification, it simply had *two distinct* implementations of objects: types, which were written in C, and classes, which were written in Python. After unification, the two kinds of object were no longer entirely distinct -- you could then subclass types in Python code, using the same class keyword as you would use for a pure-Python class. And starting with Python 3, the last vestiges of the distinction have disappeared. Now, class and type are mere synonyms. Both built-in types and custom classes use the same mechanism. I had gotten my hopes up after reading this but then I tried: $ 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On 04/15/2013 01:43 PM, Antoon Pardon wrote: Op 15-04-13 12:11, Steven D'Aprano schreef: Python's data model has always been 100% object oriented. Prior to the class/type unification, it simply had *two distinct* implementations of objects: types, which were written in C, and classes, which were written in Python. After unification, the two kinds of object were no longer entirely distinct -- you could then subclass types in Python code, using the same class keyword as you would use for a pure-Python class. And starting with Python 3, the last vestiges of the distinction have disappeared. Now, class and type are mere synonyms. Both built-in types and custom classes use the same mechanism. I had gotten my hopes up after reading this but then I tried: $ 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. No, it seems you're trying to use an internal detail as though it were a supported feature. From page: http://docs.python.org/3.3/reference/datamodel.html#types Internal types A few types used internally by the interpreter are exposed to the user. Their definitions may change with future versions of the interpreter, but they are mentioned here for completeness. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On 15/04/2013 22:13, Dave Angel wrote: On 04/15/2013 01:43 PM, Antoon Pardon wrote: [...] I had gotten my hopes up after reading this but then I tried: $ 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. No, it seems you're trying to use an internal detail as though it were a supported feature. From page: http://docs.python.org/3.3/reference/datamodel.html#types Internal types A few types used internally by the interpreter are exposed to the user. Their definitions may change with future versions of the interpreter, but they are mentioned here for completeness. To be fair, one can't do this either: Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)] on win32 Type copyright, credits or license() for more information. class C(type(lambda: None)): pass Traceback (most recent call last): File pyshell#2, line 1, in module class C(type(lambda: None)): TypeError: type 'function' is not an acceptable base type and I don't think that FunctionType would be considered an internal detail, would it? Not that I'd cite the fact that not all types can be inherited from as evidence that types and classes are not synonyms, mind. -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Tue, Apr 16, 2013 at 8:12 AM, Rotwang sg...@hotmail.co.uk wrote: Traceback (most recent call last): File pyshell#2, line 1, in module class C(type(lambda: None)): TypeError: type 'function' is not an acceptable base type and I don't think that FunctionType would be considered an internal detail, would it? Not that I'd cite the fact that not all types can be inherited from as evidence that types and classes are not synonyms, mind. Actually, I'm not sure how you'd go about inheriting from a function. Why not just create a bare class, then assign its __call__ to be the function you're inheriting from? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On 15/04/2013 23:32, Chris Angelico wrote: On Tue, Apr 16, 2013 at 8:12 AM, Rotwang sg...@hotmail.co.uk wrote: Traceback (most recent call last): File pyshell#2, line 1, in module class C(type(lambda: None)): TypeError: type 'function' is not an acceptable base type and I don't think that FunctionType would be considered an internal detail, would it? Not that I'd cite the fact that not all types can be inherited from as evidence that types and classes are not synonyms, mind. Actually, I'm not sure how you'd go about inheriting from a function. Why not just create a bare class, then assign its __call__ to be the function you're inheriting from? No idea. I wasn't suggesting that trying to inherit from FunctionType was a sensible thing to do; I was merely pointing out that slice's status as an internal feature was not IMO relevant to the point that Antoon was making. -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Mon, 15 Apr 2013 19:43:32 +0200, Antoon Pardon wrote: Op 15-04-13 12:11, Steven D'Aprano schreef: Python's data model has always been 100% object oriented. Prior to the class/type unification, it simply had *two distinct* implementations of objects: types, which were written in C, and classes, which were written in Python. After unification, the two kinds of object were no longer entirely distinct -- you could then subclass types in Python code, using the same class keyword as you would use for a pure-Python class. And starting with Python 3, the last vestiges of the distinction have disappeared. Now, class and type are mere synonyms. Both built-in types and custom classes use the same mechanism. I had gotten my hopes up after reading this but then I tried: $ 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. You are misinterpreting what you are reading. The mere fact that something cannot be subclassed doesn't mean anything. That's just a restriction put on the class by the implementation. It's not even clear that it is a guaranteed language restriction or a mere accident of implementation. With a bit of metaclass trickery, I could equally create a pure-Python class that cannot be easily subclassed. The proof that types and classes are the same in Python 3 is simple: py class C: ... pass ... py type(C) is type(int) is type(type) is type True The type of the pure-Python class is type itself. However, even this can be bypassed, using a metaclass! py class D(metaclass=Meta): ... pass ... py type(D) is type False py issubclass(type(D), type) True So when using a metaclass, the type of the class is not necessarily type itself, but it will be a subclass of type. This does not hold in Python 2.x, not for old-style classic classes. Classic classes are in a world of their own, distinct from types: # Python 2 py class C: ... pass ... py type(C) type 'classobj' py issubclass(type(C), type) False In Python 3, we can expect these two conditions to always hold: * all instances are instances of object; * all classes are instances of type. Notice that this implies that type and object are circularly defined: object, being a class, is an instance of type, but type, being an object, is an instance of object: py isinstance(type, object) True py isinstance(object, type) True These two conditions even apply to unsubclassable objects like slice: py isinstance(slice(1, 5, 2), object) True py isinstance(slice, type) True -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
On Mon, Apr 15, 2013 at 9:17 PM, Terry Jan Reedy tjre...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
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? -- http://mail.python.org/mailman/listinfo/python-list
Re: The type/object distinction and possible synthesis of OOP and imperative programming languages
Note: cross-posting to mailing lists does not work well. Hence the reply only to python-list and the gmane mirror. On 4/14/2013 11:48 PM, Mark Janssen wrote: Python is an interpreted language. I consider this a useless or even deceptive statement. Python is an object-based algorithm language. The CPython implementation (currently) *compiles* Python code to a virtual machine bytecode, similar to Java bytecode. This could change. Jython translates to Java, which is then compiled to Java bytecode. Do you call Java an 'interpreted' language? There are compilers that compile Python to the same 'object code' that C is compiled to. Since 2001, Python's has migrated towards a pure Object model. It migrated towards a pure class model. model (ref: http://www.python.org/download/releases/2.2/descrintro/). Prior to then, it had both types and classes and these types were anchored to the underlying C code and the machine/hardware architecture itself. I started with Python 1.3 and I have no idea what you mean by this. I think you are heavily confusing Python the language and CPython the implementation. After the 2001 type/class unification , it went towards Alan Kay's ideal of everything is an object. Everything has always been an object with value and identity. This stands in contrast to the assemble/C model that everything (except registers) is a block of linear memory with an address. My question is: Is there something in the Computer Science literature that has noticed this distinction/development in programming language design and history? To me, there should be, since this is a fundamental distinction in data models. I think the biggest problem in shifting from C to Python is 'getting' the data model difference. For Lispers, the difference is the syntax. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
