Everything is an object in python - object class and type class

classic Classic list List threaded Threaded
92 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Terry Reedy
On 6/3/2015 12:00 PM, BartC wrote:

> That's a different matter. However, you appear to be wrong.
>
> print (-12 is -12)
>
> gives True. As does ("abc" is "abc"). I assume constructions for
> immutable values will do the same (([10,20,30] is [10,20,30]) gives
> False because the constructs are mutable, although it's difficult to see
> how in that form).
>
> (This is on 2.7, 3.1 and PyPy. On 3.4.3, (-12 is -12) gives False as you
> say, although (12 is 12) gives True, so not even Python can make up its
> mind how it's supposed to work!)

Implementation details not specified in the language definition are just
that -- implementation details.  The 'is' operator. which is carefully
defined in the reference, has three uses:
1. test whether an object is None, or some other specific, special object.
2. for implementation developers, test whether the implementation
details, including optimizations, are as intended.
3. (least important, and often leading to confusion when people make
assumptions and extrapolate limited results) for users, discover
implementation details.

--
Terry Jan Reedy


Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

BartC-3
In reply to this post by BartC-3
On 03/06/2015 17:36, Michael Torrie wrote:
> On 06/03/2015 10:00 AM, BartC wrote:
>> The others all give True in all cases. It seems that older Python
>> versions have a purer object model.
>
> No.  It's just an under-the-hood optimization that the interpreter is
> making.  It's an implementation detail that you should never rely on.
> It says nothing about the purity of the object model.  Immutable objects
> can be optimized ("interred" is the word often used) by reusing the same
> object over and over when the interpreter can.

But (-12 is -12) yielding False was being used to illustrate why Value
and Object didn't mean the same thing.

Are they in fact the same, or is there something else that can be done
more reliably to show the difference?

(However, I feel the internal representation of values shouldn't matter.
Each type of value will have its own documented behaviour.)

--
Bartc



Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

BartC-3
In reply to this post by BartC-3
On 03/06/2015 17:29, Mark Lawrence wrote:

> On 03/06/2015 17:00, BartC wrote:
>> On 03/06/2015 13:08, Marko Rauhamaa wrote:
>>> BartC <bc at freeuk.com>:
>>>
>>>> To 'variable' and 'type', you might need to add 'value' to make it more
>>>> complete.
>>>
>>> 'Value' and 'object' are indeed synonymous as long as you keep in mind
>>> that:
>>>
>>>      >>> -12 == -12
>>>      True
>>>      >>> -12 is -12
>>>      False
>>>
>>> IOW, the literal expression -12 happens to construct a fresh
>>> value/object each time CPython parses it.
>>
>> That's a different matter. However, you appear to be wrong.
>>
>> print (-12 is -12)
>>
>> gives True.

> No, you don't understand how cPython does things.

Do I need to understand CPython to appreciate what difference there
might be between variables, values and objects?

Does anyone need to understand CPython for anything?

--
Bartc

Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Mark Lawrence
On 03/06/2015 19:59, BartC wrote:

>
> Does anyone need to understand CPython for anything?
>

No you (plural) don't.  If people were to spend more time writing code
and less time on hypothetical claptrap the amount of noise on this list
would probably be reduced by 99%.

Then knock out those who are interested in things like rugby, with
Haskell being an England international, my beautiful eight month old
great niece Ruby, and various other things, we might even spend some
time actually talking about the Python programming langauge.  Or have
you all forgotten that that is what this list is about?  Hardly
surprising that the bulk of the core devs left years ago, is it?

Oh, have to get in my obligatory mention of CORAL 66/250.  If you lot
can waffle of about languages in which I've no interest on this list,
I'll once again mention my poor old darling who gets little or no TLC.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

BartC-3
In reply to this post by BartC-3
On 03/06/2015 21:58, Mark Lawrence wrote:
> On 03/06/2015 19:59, BartC wrote:
>
>>
>> Does anyone need to understand CPython for anything?
>>
>
> No you (plural) don't.  If people were to spend more time writing code
> and less time on hypothetical claptrap the amount of noise on this list
> would probably be reduced by 99%.

Not so hypothetical in my case as I have to implement a lot of this stuff.

I'm also quite interested in how Python does things. If it's a good idea
I'll copy it, if not I'll try and avoid it!

> Then knock out those who are interested in things like rugby, with
> Haskell being an England international, my beautiful eight month old
> great niece Ruby, and various other things, we might even spend some
> time actually talking about the Python programming langauge.  Or have
> you all forgotten that that is what this list is about?  Hardly
> surprising that the bulk of the core devs left years ago, is it?

(I'm accessing the 'list' (whatever that is) via usenet. Usenet itself
is slowly dying. However I don't believe there weren't pointless
discussions that went around in circles years ago too!)

--
Bartc

Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Mark Lawrence
On 03/06/2015 22:33, BartC wrote:
> On 03/06/2015 21:58, Mark Lawrence wrote:
>
> Not so hypothetical in my case as I have to implement a lot of this stuff.
>
> I'm also quite interested in how Python does things. If it's a good idea
> I'll copy it, if not I'll try and avoid it!

Which implementation, cPython, Jython, IronPython...???

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence


Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

BartC-3
In reply to this post by BartC-3
On 03/06/2015 22:49, Mark Lawrence wrote:

> On 03/06/2015 22:33, BartC wrote:
>> On 03/06/2015 21:58, Mark Lawrence wrote:
>>
>> Not so hypothetical in my case as I have to implement a lot of this
>> stuff.
>>
>> I'm also quite interested in how Python does things. If it's a good idea
>> I'll copy it, if not I'll try and avoid it!
>
> Which implementation, cPython, Jython, IronPython...???

Mainly the language itself. But I've also been looking at the workings
of CPython. (Also PyPy but obviously I'm not going to get anywhere
there, although RPython sounds intriguing.)

(To be clear, I'm not implementing Python, but designing and
implementing a separate language.

I did try tinkering with CPython, but the only thing I discovered,
regarding its performance, is that the Windows version is probably 14%
slower than it need be. I think due to using MS' C compiler which
doesn't have gcc's computed gotos. But I think few people here use
Windows so that's probably of little interest. It's not so easy to fix
either.)

--
Bartc



Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Eddilbert Macharia
In reply to this post by BartC-3
can you please stick to the point.take your differences else where.please.....stay on target...some of us are learning... its annoying and tiring to have to read the insults and innuendo

Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Laura Creighton-2
In reply to this post by BartC-3
In a message of Thu, 04 Jun 2015 00:04:04 +0100, BartC writes:
>Mainly the language itself. But I've also been looking at the workings
>of CPython. (Also PyPy but obviously I'm not going to get anywhere
>there, although RPython sounds intriguing.)

Why not?  We built the thing for people like you who want to design
their own language.  This makes me sad.  What are we doing wrong
that you think you won't get anywhere there?

Laura


Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

BartC-3
In reply to this post by BartC-3
On 04/06/2015 11:06, Laura Creighton wrote:
> In a message of Thu, 04 Jun 2015 00:04:04 +0100, BartC writes:
>> Mainly the language itself. But I've also been looking at the workings
>> of CPython. (Also PyPy but obviously I'm not going to get anywhere
>> there, although RPython sounds intriguing.)
>
> Why not?  We built the thing for people like you who want to design
> their own language.

(I thought you wrote bookkeeping systems?)

> This makes me sad.  What are we doing wrong
> that you think you won't get anywhere there?

It's not that you're doing anything wrong. I'm just used to using my own
languages and to implementing 100% of them myself. (I have one that does
the job of C, and another that takes over the role of Python, which are
the two I'd otherwise be using.)

In the case of the interpreted one, I write streamlined but otherwise
unremarkable bytecode interpreters that can (when I add a bit of ASM)
just about compete with PyPy on small benchmarks.

(It is this latter language that I am upgrading to be more dynamic, to
make the comparisons fairer, and see if I can still maintain
performance. But I do believe a lot can be achieved with a more careful
language design.)

To make use of PyPy, I understand that I have to code my interpreter in
RPython, with various hints, and it is the execution paths in this code
that are somehow optimised at runtime.

However, I've seen at the video someone posted of the keynote talk about
PyPy (https://youtu.be/l_HBRhcgeuQ), and it does look a rather
intimidating process (apparently taking several hours to compile the
smallest code tweak; currently it takes me about 1 second to try
something new).

Also, I'm using Windows where even ordinary Python development doesn't
really work; I had to use Ubuntu (a completely alien environment to me)
to attempt compiling Cpython).

--
Bartc

Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Laura Creighton-2
In a message of Thu, 04 Jun 2015 13:01:00 +0100, BartC writes:

>On 04/06/2015 11:06, Laura Creighton wrote:
>> In a message of Thu, 04 Jun 2015 00:04:04 +0100, BartC writes:
>>> Mainly the language itself. But I've also been looking at the workings
>>> of CPython. (Also PyPy but obviously I'm not going to get anywhere
>>> there, although RPython sounds intriguing.)
>>
>> Why not?  We built the thing for people like you who want to design
>> their own language.
>
>(I thought you wrote bookkeeping systems?)

Yes, but I have to do something for fun, now, too don't I?  There is only
so much fun you can get out of a bookkeeping system.

>> This makes me sad.  What are we doing wrong
>> that you think you won't get anywhere there?

snip

>To make use of PyPy, I understand that I have to code my interpreter in
>RPython, with various hints, and it is the execution paths in this code
>that are somehow optimised at runtime.
>
>However, I've seen at the video someone posted of the keynote talk about
>PyPy (https://youtu.be/l_HBRhcgeuQ), and it does look a rather
>intimidating process (apparently taking several hours to compile the
>smallest code tweak; currently it takes me about 1 second to try
>something new).

We have a way to run the tests without compiling the whole thing every
time.  Not quite the same, but not quite as horrible as you might imagine.
And, happy news, Armin has had a new idea.
https://mail.python.org/pipermail/pypy-dev/2015-February/013085.html
When this goes in, warmup times will get much faster, which will mean
that everyting goes a lot faster.  (We think.  In theory.  We will
see.)

>Also, I'm using Windows where even ordinary Python development doesn't
>really work; I had to use Ubuntu (a completely alien environment to me)
>to attempt compiling Cpython).

PyPy development on Windows has gotten a whole lot better since that
keynote -- what it took was getting some PyPy developers who use
windows.  But they are still in short supply.  And yes, it is probably
still easier for linux people.

But if one of your goals is better performance, well, python-list
isn't the place to find the people who spend most of their lives
thinking about such things.  Whereas pypy-dev is one such place.

>--
>Bartc
>--

At any rate, if there is any interest you can come visit the irc channel
on freenode, or send mail to pypy-dev, which isn't gatewayed to usenet
anywhere.  https://mail.python.org/mailman/listinfo/pypy-dev

You won't get philosophical notes about the meaning of objects
and the like there.  It's a pretty down-to-earth-and-here-is-the-code
and 'you are slow because you do X do Y instead' sort of place.  But
polite and friendly.

Laura

Reply | Threaded
Open this post in threaded view
|

Everything is an object in python - object class and type class

Steven D'Aprano-8
In reply to this post by BartC-3
On Thu, 4 Jun 2015 03:26 am, BartC asked about Value and Object:

> Are they in fact the same, or is there something else that can be done
> more reliably to show the difference?

In *Python*, they are the same. All values are implemented as objects.

But, speaking generically, Value and Object are as different as Value and
String, or Value and Integer, or Value and List. Objects are a specific
kind of value. Values may be:

- simple machine-specific types like byte, int16, single (float);
- simple compound types like array, record or struct, string;
- more complex compound types, such as objects (in the Object Oriented
Programming sense).

An object in this sense is basically a record or struct with added language
semantics. So in a language like Pascal, for example, there are a bunch of
machine-specific simple unstructured types:

    Real, Boolean, Char, Integer, ...

plus machine-specific compound types:

    Array, Record, String, ...

plus Objects (at least for recent enough Pascal compilers). In Java, for
example, you have "unboxed primitives" for various integer types,
and "boxed" objects.

In Python, all values are Objects:

- ints are low-level integers wrapped in an Object;
- floats are low-level C doubles wrapped in an Object;
- strings are arrays of characters wrapped in an Object;

etc.


> (However, I feel the internal representation of values shouldn't matter.
> Each type of value will have its own documented behaviour.)

Well, sometimes it might matter. My own feeling is that languages shouldn't
lie to you. If it offers both low-level primitives for efficiency and
high-level objects for convenience, it should make the difference explicit,
like Java does, or Pascal, or C++. Javascript tries to hide the difference,
which works really well until it doesn't, and then you get weird behaviour:


js> arr = [false, Boolean(false), new Boolean(false)];
false,false,false
js> for (i = 0; i < arr.length; ++i) {
  > print(arr[i]);
  > if (arr[i]) {print("Surprise!")} }
false
false
false
Surprise!


If you can come up with a sensible justification for why Boolean(false) is
falsey, but new Boolean(false) is truthy, you're a better man than me.

 

--
Steven


12345