Python is not Java or C++

16 Jan 2018

I’m looking for more surprising things about Python if you’re coming from Java/C++ for a talk I’m giving soon. Email me at me@ballingt.com or tweet at @ballingt with any ideas!

Thanks for taking a look.

What’s tricky for someone coming from Java or C++?

  • Looks similar to Java or C++, but is different
  • Differences that are rarely observed
  • Differences that aren’t visible in code

Look similar, behave differently

In natural languages these are called false friends.

  • Decorators look annotations in Java, but decorators are surprisingly more powerful
  • class attributes in Python look remarkably like initializing a member of instance attribute in Java or C++! This is sneaky because until you have multiple instances this might appear to work.
  • imports in Java and C++ aren’t conditional! So conditional, runtime imports (dynamically loading code!) might be surprising
  • hiding ways to introduce assignment: see Ned’s talk slide. These all create a binding or reassign a variable if one by that name already exists.
  • equals: it’s always a reference, mostly like Java. But v. different than C++ where it’s a copy.
  • block scope: In Java and C++ there’s something called block scope. It’s would be like if every indented block in Python got its own locals()! So they are surprised when e.g. the variables in a for loop escape from the loop.
  • static types: not checked by python, need an external program (mypy)

Often behave similarly

  • closures: C++ lambdas always specify, so expect a C++ programmer to wonder which of the many possible behaviors closures have in Python, while someone familiar only with Java might assume the wrong behavior: that closing over variables makes them final
  • __del__ will usually act like a C++ finalizer, but not for gc’d objects
  • GC is more predictible than Java, but less than C++
  • super() constructor calls don’t happen automatically
  • and multiple inheritance allows one parent class to prevent calling into another’s __init__!
  • attribute lookup - choosing the method/property to grab/modify is SOOOO runtime
  • class attribute lookup is never static if it happens on an instance (don’t expect the static behavior from Java/C++)
  • threading! Often seems to work similarly, but GIL
  • properties - Java an C++ use getters/setters to customize get/set behavior, so might be surprising that something that looks like setting an attribute actually runs arbitrary code

Invisible

  • monkeypatching - implications!
  • exceptions used for control flow
  • metaprogramming is way less verbose than Java introspection, a couple characters and you might miss it
  • tabs vs spaces in Python 2: very hidden that 8 spaces = 1 tab

That’s the list of topics I’ve got, I’m making slies for some and thinking about categories. The rest of this post is transcript-like more or less what I’ll be saying for the first 5 minutes of the talk.


Thanks so much for coming, I’m excited to be here today. I have exciting news for you:

Python is not Java, nor is it C++

It’s different! Let’s talk about how Python is different from Java and C++.

Why?

And let’s do this with some very specific motivation: someday you may have colleagues or collaborators that don’t know Python as well are you do, but do know another programming language.

My background

I work at Dropbox: a company with a few hundred software engineers, many of whom have a lot of experience. Dropbox uses Python for all sorts of things - I work on the desktop client, which is primarily written in Python. When a new engineer joins my company or my team, they might not yet know Python very well.

So do they take a few months off to focus on learning? (btw this is a fun thing to do!) No. They start writing production code pretty quickly. They read books (my favorite is David Beazley’s Python Essential Reference) and watch excellent Python talks (Ned batchelder talks, Raymond hettinger talks), and they ask more experienced collegues questions.

So I can help them by teaching, by recommending these resources, by reviewing their code to protect them from some of Python’s sharp edges. I’m more effective at all of these types of communication when I understand their understanding of Python.

Python-as-a-secondary-language empathy

To best support them you will need Python-as-a-secondary-language empathy. (PSL)

The best way to build Python-as-a-second-language empathy would be to forget everything you know about Python, learn to program in their language, and then learn Python. This is hard for most of us to do, but it might be a superpower you already have: remeber what seemed strange and suspicious about Python when you were learning it.

You can listen. This is where I believe Ned Batchelder gets his empathy: thousands of hours in the #python IRC channel and at conferences and meetups listening and offering help, he notices patterns that lead him to write some of my favorite talks. Listen and help, and notice patterns about what’s confusing.

You can learn the other language! What confuses you, what can you imagine being confusing?

You can learn any other language: programming languages are different from each other along many axes. Consider the code:

a = b + c

Will a always be equivalent to the sum of b and c from now on, or will that only be true right after we run this code? Will b + c be evaluated right now, or when a is used later? Could b and c be function calls with side effects? Which will be evaluted first? What does plus mean, and how do we find out? Is a a new variable, and if so is it global now? Does the value stored in a know the name of that variable?

If you learn a language that works a different way, Even if you forget the particulars of a programming language, you might remember the ambiguity; it could be a bridge to understanding a foreign worldview.

Finally, you could just really pay attention to the rest of this talk: we’re going to look at a cheat sheet of things that might be especially tricky for Java and C++ developers learning Python.

Why Python vs Java and C++?

We’re at a Python conference; by being here, you’re taking a serious step towards fluency in the language.

Python is getting big!

And you can see Java and C++ in there too.

Another time-sensitive communication task I do at work is interview candidates. Often computer science undergrad programs will teach C++ or Java - so being able to explain things in terms of these will be useful.

What’s Isn’t Tricky?

The colon following an if statement or def statement may not be easy to remember, but there’s a very short feedback loop. Almost any syntax error is going to be caught when we first import a file, so as long as you can read error messages - a considerable skill, but one Java and C++ programmers might be able to pick up quickly - this won’t be tricky. By tricky I mean something someone I work with might not have noticed yet, despite being a few weeks, months or years into using Python. asfd as f

What makes something tricky?

  • Internal inconsistencies

List comprehensions look like this:

[f(x) for x in xs]

and set comprehensions look like this:

{f(x) for x in xs}

and dictionary comprehensions look like this

{x: f(x) for x in xs}

So naturally

(f(x) for x in xs)

must be a tuple comprehension?

Nope, it something completely different (it’s a generator expression). This is tricky because it’s inconsistent. But I think this might be tricky for anyone learning Python.


differences list goes here


What do we do with this cheat sheet?

  • Teaching!
    • be excited to teach - even if you can’t afford the time
    • Don’t assume people don’t know this stuff - most of the time people do know 80% of it

Other things we can do about differences

  • don’t use fancy features
  • the py2/3 approach
  • code review
  • linters

concluding thoughts

language expertise: not actually that useful! I want to see more diff cheat sheets!