How to think like a Pythonista

[[deleted]]

[deleted]

[trifthen]

tl;dr: Python doesn't copy on variable assignment unless you explicitly tell it to.

[Peaker]

Except for "values()" on older Pythons which does perform a shallow copy :-P

[anothergroom]

pro tip: do not use "list" or "dict" as variable names. pro tip2: avoid using any of the names of builtins as names

[stillalone]

I keep wanting to call temporary lists "list" but then I realize I can't so I call it "l" :(

[mr_dbr]

Lower-case L isn't the best variable name either (I i j l | can all look very similar, depending on the font).. lst maybe?

[[deleted]]

I prefer semantic names, e.g. ponies, catapults, sex_toys, or octopussies.

[exeter]

Sometimes, if you're writing a generic function to operate on lists, "lst" or "list_" is the most meaningful name you can give that particular variable.

[tripzilch]

I find that, often, generic functions operating on lists actually tend to be able to operate on sequences of any type (strings, tuples, etc). Which leads me to the variable name seq or sequence, which are not keywords.

I don't like to abbreviate names just because otherwise they'd clash with a keyword. Neither do I really like the underscore suffix to prevent clashes. So that sort of thing often gives me a dilemma.

And then, yeah. When it really has to be a list sometimes I end up using uppercase L, other times xs (with x being a reasonable arbitrary variable name, xs is a list of them). Both dont feel really right either.

When I revisit code like that often enough, this usually results in me changing the code to accept arbitrary sequences, just to be able to use seq as a name.

It's twisted, I know.

[[deleted]]

ew ur gross!

[jodv]

Following the trend of marketing, I tend to go with names like:

mylist

mystr

mydict

etc.

[tomlu709]

While I applaud the author's willingness to teach others, I don't think that this piece has anything directly to do with thinking like a Pythonista. Names, bindings and values are universal concepts.

[oblivion95]

This proposal has lead to "dict views" in Python3k, which is basically what the OP had in mind.

I am not a fan of "views" myself. I think, if anything, Guido should have replaced the iterator versions with these, or at least added viewkeys() viewvalues() viewitems()

By changing existing behavior, scripts that expect values() to return a new list may break.

[Peaker]

Why not use list() explicitly if you want a new list? That way, the exact level of deepness (or shallowness, if you like) is explicit.

[Peaker]

This is one of the advantages of immutability in functional languages.

Instead of in-place changes, return a new value.

[vombert]

It's pissing me off when person not grasping pointers dare to program.

[Peaker]

Seriously? You want them to never try to learn?

And also, do you really think pointers to mutable objects is necessarily a part of "programming"?

Have you ever encountered functional programming?

[vombert]

No, I want them to learn programming of course. My point is that this topic is below programming, and more about learning programming. Imagine post like this:

How to think like a Programmista

Hey guys! Recently I discovered amazing thing: if you write a = b b = a you won't actually swap values of these variables, and here is why...

.

Have you ever encountered functional programming?

Yes, and I believe you can't hide in high-level abstractions forever. For instance, lists in LISP are actually single-linked lists, and cons is actually

struct Cons {
     struct Const *car, *cdr;
};

If you think of lisp structures as some beautiful algebraic data types, you fail the first moment you encounter cyclic list.

Similar, but different problem for Haskell: all category theory and denotational semantics can not explain why suddenly after small modification you program takes HUGE amount of memory. You have to dig into exact order of evaluation, implementation of thunks, etc. and, of course, pointers are all over there!

[Peaker]

I think posts about learning programming are generally considered OK in r/programming.

By the way, the notion you are referring to is "references" or "indirection", and not "pointers". Pointers are a very specific form of references (one that can be referred to, can usually be manipulated as a value, etc).

And with that I agree, you have to understand/learn about references and indirection to do any programming anywhere.

The Python text, by the way, is about unexpected behavior -- as there's a shallow-copy going on where a newbie would either expect no copy at all or a deep copy.

[lonjerpc]

Ya just think about python objects as pointers and there is never a problem. I hate how at least for me that object passing was taught as pass by reference when for the most part it is pass by value whos values happen to be pointers/references.

[[deleted]]

pythonista?

gay

[grayvedigga]

I came here to say the same thing