Category Archives: python

community, python , 10 Comments

Code review for the new PyLadies in your life

This goes out to all the geeky spouses, partners and friends of brand new programmers:

Code review is a cultural practice.

When you sit down to read the work of another, you bring with you all the experience you’ve had up to that point, the code reviews you’ve received, the mistakes you see yourself making and the bits of hard-won knowledge embedded in your coding personality.

Basically, you bring your coding baggage into your review.

When a brand new programmer shares their code with you, they are fundamentally vulnerable. They’re sharing something creative, and like any new creative endeavor, the product is a newborn taking it’s first few, shaky steps.

They are asking for your help and very likely, they’re asking for an indication that they’ve accomplished something. That all the time they just invested in learning something new — paid off.

And, in the case of PyLadies, women are all stepping out on a limb. Some are taking a Coursera class or maybe a workshop, but mostly working alone. We have each other to learn with and we’re all learning something new. Many people are spending 2 nights a week with a group, and another 15-20 hours a week struggling through the very first programs they’ve ever written.

Here’s the very best thing you can say when a PyLady shares her code with you:

“Thanks for sharing this!”

And then, after you’ve had a look:

“I’ve had a look and you’re doing a great job. Tell me about what you’ve written.”

Seriously. That’s about it.

If the PyLady asks specific questions, give your answers. Keep it short and sweet, and encouraging.

I’m laying this out because lots of the women who are trying this stuff out for the first time have loving, geeky spouses and friends who are very excited that the women in their lives are learning to speak their languages. And some of that enthusiasm comes in the form of detailed critique of style, formatting and design.

I’m here to let you off the hook. Just be encouraging, and ask a few open ended questions. That is all you need to do.

Because the reality is: the PyLady is her own worst critic. And, when she comes to a meetup, she can get the detailed help she needs from the other women who are struggling right along with her.

The people in the group have earned the right to share and receive feedback by strugging together. That’s the value of a cohort and one reason why PyLadies, and groups like them, are so important.

If you’re lucky, you’ll get your chance to share some code back, and maybe even write something together. But you build that coding relationship one encouraging step at a time.

If you’re interested in joining PyLadies-PDX, we’re meeting weekly through December, and then starting Monthly meetings on January.

And, if you want to read more about code review in general, here are some additional blog posts I found useful:

python , , ,

Learning python the hard way: print vs sys.write, and python -u

I knew before that print in Python had some weird properties. Like:

>>> for i in [1, 2, 3, 4]:
... print "blah"
...
blah
blah
blah
blah
>>> for i in [1, 2, 3, 4]:
... print "blah",
...
blah blah blah blah

One thing you’ll notice is that there’s a space between each of the blahs. If you don’t want those spaces, you need to use sys.write. Here’s an example of using sys.write along with a progress bar indicator. Which is exactly what I wanted this for.

Finally, you can indicate to python on the command-line that you want unbuffered stdin and stdout with python -u.

python , ,

Learning Python the hard way: __init__.py needed for packages (as opposed to modules)

Just ran into this today, and wanted to get it down so I never forget:

Modules are not packages! :)

From the docs, a Module is:

A module is a file containing Python definitions and statements. The file name is the module name with the suffix .py appended. Within a module, the module’s name (as a string) is available as the value of the global variable __name__.

And a Package is:

Packages are a way of structuring Python’s module namespace by using “dotted module names”.

When you create a module and you want other scripts to be able to reference it, you need an __init__.py in the directory containing the modules in order for Python to treat a directory as containing a package.

The error manifests as “ImportError: No module named XXXX”.

All I had to do was touch __init__.py and things worked. I’m sure there are other things I’m going to learn today, but that was a silly one that I didn’t expect, and wasn’t mentioned in the Modules documentation, but is mentioned in Packages.