[Edu-sig] names versus objects, reference counting etc. (was Code to Joy...)

kirby urner kirby.urner at gmail.com
Sun Jun 3 23:32:32 EDT 2018


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
​
Kirby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20180603/942ea893/attachment-0001.html>


More information about the Edu-sig mailing list