Re: names versus objects, reference counting etc. (was Code to Joy...)

On Sunday, June 3, 2018, kirby urner <[email protected]> wrote:

> Responding to the most recent by Wes...
>
> Excellent & Comprehensive.  Thanks for bringing sys.refcount to the table.
>
> I think newcomers sometimes grow in confidence when they get these peeks
> into back stage behind-the-scenes stuff.
>
> As long as we express it clearly, we're putting folks on a fast track to
> becoming "insiders".
>  ​
>
>> # We usually don't ``del(variable)`` in Python because the garbage
>> collector will free that memory anyway whenever it happens to run and the
>> refcount is zero because the variable has fallen out of scope.
>> #
>>
>
> A tiny point:
>
> del variable
>
> is slightly more correct than
>
> del(variable)
>
> following the rule that "no keyword is a callable".
>
> You have it right in your dialog with the interpreter.
>
> Remembering that rule saves people treating if and return as callables as
> well, which I consider an "accent".
>
> if(condition):
>    return(object)
>
> Still works.  You see this when students are coming from other languages.
>
> Just the parens aren't doing anything.
>
> >>> import keyword
> >>> keyword.kwlist
>
> A list of not-callable names.
> ​
>
>> # In practice, we name global variables in ``ALL_CAPS`` (and may expect
>> them to be constants). We wrap 'private' variable names with dunder
>> (``__variable__``) so that other code can't modify those object attributes
>> (due to 'name mangling').
>>
>
>
> ​I believe best practice is to put the double-underlines only on the left
> e.g.  hidden = __variable
>
> The two underlines on the left side are sufficient to provoke name
> mangling.
>
> The rule here is:  Python provides us with the special names ( __ribs__ );
> we don't create them.
>
> ​
>
>> Sometimes, we name variables with a single ``_underscore`` in order to
>> avoid a 'variable name collision' with outer scopes (or to indicate, by
>> convention, that a variable is a local variable)
>> #
>>
>
>
> ​Yes.  I tell people the _semi_private names are not guaranteed to stay
> the same from version to version i.e. the coder is telling the code reader
> "use this at your own risk, I'm not guaranteeing it'll still be there
> later".
>
> I.e.  _semi_private names are not part of the official API, are
> specifically excluded therefrom.
>
> Often used for method names internal to classes.
>
> The same goes for __super_private, only more so.
>
> ​
>
>> # In practice, we try to avoid using globals because when or if we try to
>> add threads (or port to C/C++), we're never quite sure whether one thread
>> has modified that global; that's called a *race condition*. Some languages
>> -- particularly functional languages like Haskell and Erlang -- only have
>> mostly all immutable variables; which avoids race conditions (and the
>> necessary variable locking that's slowing down Python GIL removal efforts).
>>
>
> ​Yes, in practice best to have globals be immutable type objects, not a
> place to store state.
>
> I think of the django settings.py and other such config files as places to
> store framework-wide globals.
> ​
>
>> #
>> # Is it a box or a bucket?
>> # It's a smart pointer to an allocated section of RAM.
>> #
>>
>
> ​The allocated section of RAM is the box or bucket.
>
> Names and Objects are distinct.
>
> Names (pointers) go to the left of the assignment operator, Objects
> (containers) to the right of same.
> ​
>
>> # When do we get a new box and throw an old one away? Is there a name for
>> the box and the thing in the bucket? Does the bucket change size when?
>> #
>>
>
> ​Bucket = Box = Object (on the heap).
>
> Name = Post-it = Label = Tag
>
> https://flic.kr/p/DQb8t6
>
> Names must take up a little bit of memory too.  Very long names take up a
> little more.
> ​
>
>> # I think the box/bucket metaphor is confusing and limiting; but I've
>> been doing this for a long time: it's a leaky abstraction.
>> #
>> # - https://en.wikipedia.org/wiki/Memory_leak
>> # - https://en.wikipedia.org/wiki/Race_condition
>> # - https://en.wikipedia.org/wiki/Smart_pointer
>>
>>
> ​Lets not forget weakref  -- worth bringing in right when we're talking
> about garbage collection and reference counts.
>
> https://docs.python.org/3/library/weakref.html
>

/search objects values reference site:docs.python.org

Here's a better site:docs.python.org query:

https://www.google.com/search?q=objects+values+reference+site%3Adocs.python.org

- https://docs.python.org/3/reference/datamodel.html
  - assert id(A) == id(B)
  - assert hash(A) == hash(B)

-
https://docs.python.org/3/reference/datamodel.html#objects-values-and-types

-
https://docs.python.org/3/c-api/intro.html#objects-types-and-reference-counts

-
https://docs.python.org/3/c-api/allocation.html#allocating-objects-on-the-heap

  - PyObject_Init
  - PyObject_Del

Python Tutor is a web-based way to step through code examples:
http://pythontutor.com/visualize.html#mode=edit


> ​
> Kirby
>
>
>

_______________________________________________
Edu-sig mailing list
[email protected]
https://mail.python.org/mailman/listinfo/edu-sig