On Sunday, June 3, 2018, kirby urner <kirby.ur...@gmail.com> 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 Edu-sig@python.org https://mail.python.org/mailman/listinfo/edu-sig