Everything is an object in python - object class and type class
BartC
bc at freeuk.com
Wed Jun 3 06:20:17 EDT 2015
On 03/06/2015 05:16, Eddilbert Macharia wrote:
> On Tuesday, June 2, 2015 at 2:27:31 PM UTC+3, Steven D'Aprano wrote:
>> Eddilbert, have you programmed in any other languages? It would help you
>> understand if you have.
>
> Sadly yes i have worked with java, and that is what is causing me so much grief.In java objects are instance of a class.pretty simple.
>> In Python 2:
>>
>> - everything is an object [the general concept]
>>
>> - some things, but not all things, are instances of the class
>> called "object"
>>
>>
>> In Python 3:
>>
>> - everything is an object [the general concept]
>>
>> - everything is an instance of the class called "object"
> I think then in python object and instance of a class are entirely different things.
>
> in OOP and python - object is a representation of a real thing, or a concept .e.g a person,number and the concept of classes- which is the concept of create/representing other objects using a programming language to the machine.
>
> class - This is what is used to create/represent objects in the machine using a programming language
>
> class instance - This is the output of the classes this is a representation of an object.
I have a lot of trouble with this stuff too, as my ideas are decidedly
old-fashioned. (Also I'm developing a language with some OO aspects
without ever having used OO!)
But, it is mostly just jargon. If you go back to using 'variable' and
'type', then it becomes a bit easier:
* A variable is an instance of some type.
And, that's pretty much it!
However, modern languages such as Python add a few more twists. So, if a
static, compiled language, say, had these kinds of things:
- Module
- Record definition
- Enum type
- Label (for goto)
- Function
- Type
which are normally entities that only the compiler are concerned with,
then these can now also be values that can be stored in variables! (One
or two such languages might allow pointers to Functions or Labels, but
that's about it.)
Exactly what it is about a Module, Record or Function that is stored in
the variable is an implementation detail. The important thing is that
you can use such as variable at runtime in the same way you might do at
compile-time.
Python of course would subsume concepts such as Records or Enums into a
class, as it seems to like to unify what it considers to be untidy,
separate aspects of a language. Some of us however need things separated
out again in order to understand them!
(This is a set of codes I'm using in a current compiler project, for a
new language. Each denotes a separate kind of identifier in the input
source:
nullid = 0
programid = 1
moduleid = 2
extmoduleid = 3
classid = 4
procid = 5
staticid = 6
constid = 7
fieldid = 8
genfieldid = 9
enumid = 10
paramid = 11
frameid = 12
varid = 13 # ?
labelid = 14
blockid = 15
attribid = 16
aliasid = 17
The language requires that each identifier is resolved at compile-time
to one of the above. This makes it rather less dynamic than Python,
where the bytecode compiler, as far as I know, only resolves a name as
either global or local (and perhaps attribute, but I'm not an expert on
its workings).
(The 'varid' code was for a unresolved top-level name, which I will
probably remove as that was added when I'd intended to emulate Python
more. But that was too much work (and too many speed-ups were no longer
trivial). Some codes such as 'nullid' and 'programid' are only used
internally.
'genfield' is a field (attribute) that can't be resolved, but the
possibilities have been reduced to a small, finite set which is
resolved at load-time (in Python, the attribute could be anything, and
you don't even know at runtime what it might be until you actually use
the attribute.)
In this list, then 'static', 'frame', and 'param' denote what I'd call
variables. A variable, at runtime, contains a value of a certain type
(another list of codes). One of those types however is a Symbol: just a
reference (a symbol table index) to a resolved name in the source code.
Just a different approach to things. But since the ultimate aim is to be
able to write programs, not so different.)
--
Bartc
More information about the Python-list
mailing list