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