On Wed, Feb 20, 2019 at 5:28 AM Grant Edwards wrote:
>
> On 2019-02-19, Chris Angelico wrote:
> > On Wed, Feb 20, 2019 at 3:23 AM Grant Edwards
> > wrote:
> >
> >> Those object _may_ each have different identies. Is it required that
> >> they do? If an assignment is done on name referring to
On 2019-02-19, Chris Angelico wrote:
> On Wed, Feb 20, 2019 at 3:23 AM Grant Edwards
> wrote:
>
>> Those object _may_ each have different identies. Is it required that
>> they do? If an assignment is done on name referring to an object with
>> no other references, would it be allowed that the
On Wed, Feb 20, 2019 at 3:23 AM Grant Edwards wrote:
>
> On 2019-02-19, Ben Finney wrote:
>
> >> On the implementation I am using, the ID changes if I do this:
> >
> > You are creating new objects and binding the name ‘a’ to different
> > objects in succession. Those different objects will each
On 2019-02-19, Ben Finney wrote:
>> On the implementation I am using, the ID changes if I do this:
>
> You are creating new objects and binding the name ‘a’ to different
> objects in succession. Those different objects will each have different
> identities.
Those object _may_ each have
Stefan Ram wrote:
What's so important about the (presumed) address of a
function that it is shown on every stringification of
each function?
Its value isn't important at all. It's just a way of
distinguishing different objects in debugging output.
--
Greg
--
"Avi Gross" writes:
> I hear that [the ‘id(foo)’ return value] is implementation dependent.
> But are there any requirements on the implementation that allow it to
> have meaning?
The requirements are that `id(foo)` should satisfy the documented API
for that function
On Tue, Feb 19, 2019 at 7:04 AM Avi Gross wrote:
> How about functions?
>
> Even more confusing:
>
> >>> def a(): pass
>
> >>> def b(): pass
>
> >>> id(a), id(b)
> (13123280, 13201816)
> >>> b=a
> >>> id(a), id(b)
> (13123280, 13123280)
> >>> def a(): return True
>
> >>> id(a), id(b)
> (13201816,
On Tue, Feb 19, 2019 at 7:04 AM Avi Gross wrote:
>
> Alister wrote about the meaning of the id number often displayed about a
> python object:
>
> > it is the internal id of the function - Not necessarily an address, that
> is an implementation detail.
>
> > it is not intended for use within a
ect. Well, I assume that means that anything else set
to be the same as the original as in "a = b" will share that ID. Once an
object is gone, the ID can be reused.
This may help understand some of the above results especially since memory
management may not rapidly get rid of something. I concu
On Mon, 18 Feb 2019 11:59:18 +, Stefan Ram wrote:
> When one prints a function, one might get something like:
>
>
>
> . The participants of my basic course asked me what the address is
> for. I did not know.
>
> What's so important about the (presumed) address of a function that it
10 matches
Mail list logo
