In general, a descriptor is an object attribute with “binding behavior”, one whose attribute access has been overridden by methods in the descriptor protocol.

What is binding behavior, and why is it in quotes? This lead sentence hints at overriding attribute access, but doesn't tell me how it happens. It's a tall wall to scale right at the start of the learning process.

The best explanation I've seen of what descriptors do and why you'd want to write them was in Chris Beaumont's lightning talk at Boston Python, Demystifying Descriptors in 5 Minutes. The video quality was not great, but now Chris has written it up: Python Descriptors Demystified.

(Sorry about the quality, we're getting much better... PS: subscribe to our YouTube channel!)

Chris' insight was that instead of defining descriptors, and then showing how you could make properties with them, he flipped that explanation around: explain properties, then show how descriptors are like generalized properties. Read the whole thing: Python Descriptors Demystified.

When explaining things, you have to build from what people already know, a step at a time. I picture a student's understanding being like geography. What they know is a land mass, and when you teach them, you are extending their land out into the unknown ocean. You want to make their island bigger, and there's a particular point out in the ocean you want to encompass.

Some technical descriptions will explain that distant point, and either hope you can build the peninsula yourself, or expect to be able to build backwards toward the mainland. The classic descriptor explanation is like that: provide a definition of the distant concept, and hope students can make the leap.

Chris' explanation is more incremental. Start with what we know, and extend a little bit at a time, with motivations as we go. I love it.

BTW: I made some edits to the Python documentation, but they haven't been adopted: Edits to descriptor howto. Others have also suggested reorganizations of the docs about descriptors: Harmonizing descriptor protocol documentation.

Descriptors are still an advanced feature, and I don't expect everyone to understand and use them. But they are not as complicated as they first seem, and the explanations can do a better job helping people up that learning curve.

The museum is a fun place, with lots of interactive exhibits. Some were intriguing but baffling, like a polyhedron exploration device which looked great, but was impossible to control. We rode square-wheeled tricycles, made ourselves into fractal trees, explored cross-sections in the wall of fire, rolled weird shapes to make weird paths, looked at specular holography, and so on.

As is typical with these kinds of high-traffic interactive displays, a number of them were not working, which was disappointing. But overall, it was a lot of fun, and not the same feel as math class at all. One helpful museum worker kept popping up to tell us how to better use the exhibits, and Susan said, "if I had her as a math teacher, I might have learned something in high school!"

It was a great day. If you enjoy mathematical thinking, I heartily recommend the Museum of Math.

A few blocks north, we found the Museum of Sex, but decided not to go in with the kids....

The question was by Roy Smith. He asked about dividing a list of songs into two lists based on a predicate, like this:

new_songs = [s for s in songs if s.is_new()]
old_songs = [s for s in songs if not s.is_new()]

but without iterating the list twice and calling the predicate twice for each element. He also provided this implementation, which iterates the list only once:

new_songs = []
old_songs = []
for s in songs:
    if s.is_new():
        new_songs.append(s)
    else:
        old_songs.append(s)

which got shortened to:

new_songs, old_songs = [], []
for s in songs: 
    (new_songs if s.is_new() else old_songs).append(s)

This works just fine for a simple list, but suppose the original sequence to be divided was a generator, and you don't want to buffer all the values in memory? Is there a way to do this lazily?

Usually, we go to the itertools module for things like this, but this problem is tricky: we need to get two lazy iterators at once.

Chris Angelico came up with this remarkable machine, with a deque tweak by Tim Chase:

def iterpartition(pred, it):
    """Partition an iterable based on a predicate.

    Returns two iterables, for those with pred False and those True.
    """
    falses, trues = collections.deque(), collections.deque()
    it = iter(it)
    def get_false():
        while True:
            if falses: 
                yield falses.popleft()
            else:
                while True:
                    val = next(it)
                    if pred(val): 
                        trues.append(val)
                    else: 
                        break
                yield val
    def get_true():
        while True:
            if trues: 
                yield trues.popleft()
            else:
                while True:
                    val = next(it)
                    if not pred(val): 
                        falses.append(val)
                    else: 
                        break
                yield val
    return get_false(), get_true()

Here two generators are created as closures, and returned as the result of the function. The generators cooperate to work over the original iterable, calling the predicate only once for each element, and buffering only enough values to find the next one you want.

Peter Otten contributed this gem:

def partition(items, predicate=bool):
    a, b = itertools.tee((predicate(item), item) for item in items)
    return ((item for pred, item in a if not pred),
            (item for pred, item in b if pred))

Here we finally have itertools helping us. This behaves like Chris' code, buffering enough values for either returned iterable to provide the next requested value. But we don't have to do the buffering, itertools.tee does it for us, and the predicate is called only once for each element in the iterable. Itertools.tee gets a generator expression that produces the original elements along with the result of calling the predicate. That is tee'd into two iterables, which are then fed to two generator expressions to select the proper values. Clever.

When I first read the question on the list, I didn't see how to improve on the list-building code. Now I've got two interesting implementations, and I learned a few things!

So here's a question for people who remember coming up from beginner: as you moved from exercises like those in Learn Python the Hard Way, up to your own self-guided work on small projects, what project were you working on that made you feel independent and skilled? What program first felt like your own work rather than an exercise the teacher had assigned?

I don't want anything too large, but big enough that there's room for design, and multiple approaches, etc.

If you came to Python from another programming language, then what was the project that first made you feel competent at programming in general?

Any and all ideas welcome. Thanks in advance!

For example, many of the stones had y^e in place of "the." That y isn't actually a y, it's a thorn, a letter that fell out of use in English a few hundred years ago. Thorn is prounounced th, so y^e isn't "yee", it actually is "the."

After noticing how older stones had y^e and newer ones had "the", we came across Mary Ela's stone:

It reads:

HERE LYES BURIED
THE BODY OF M^rs.
MARY ELA WHO
DEC^D. MARCH Y^e 6.
1 7 3 7_/8
IN Y^e 55. YEAR
OF HER AGE.

The odd thing here is a single gravestone that has both THE and Y^e. Why use both forms? Why in one place but not the other? Perhaps because the English sentence flowed more naturally, but the dates and age felt like a conventional form?

The other transitional note is the date: 1737/8. The 7-or-8 was not because her date of death was unknown. It's because the world didn't agree on how to number years.

Our current calendar is the Gregorian calendar, a work of some engineering and design. Before 1752, years started on the vernal equinox, around March 21st. It wasn't until 1752 that people agreed that the number of the year should be incremented on January 1st. In 1737, some people used year numbers incremented on January 1st, and some used years incremented in March. Since Mary Ela died in early March, some would have called the year 1737, but some would have called it 1738. Putting both numbers on the gravestone makes it clear when she died.

By the way: the year starting in March explains why September, October, November, and December are named as the 7th, 8th, 9th, and 10th months: if you count March as the first month, then the numbering makes perfect sense.

It's fascinating to think back to those times. We deal now with confusing timezones and character sets, but at least the English alphabet and the number of the year are simple, right? Well, back in 1737, you couldn't even count on that.

Which is correct?

I guess I was modeling .coveragerc on .bashrc, .vimrc, and all the other files that clutter home directories everywhere. But is that right? I asked on twitter a few months ago:

Should config files have initial dots or not? tox.ini vs .gitignore, for example. Reasons?

A few people said they should have dots if they are in your home directory, which is clearly true. But these config files are not meant for the home directory.

Larry Price responded,

essential versus incidental, .gitignore or .bashrc are incidental to any given task, but tox.ini or settings.py are the task itself.

Hmm, an interesting point. So is .coveragerc essential to coverage.py? It's only for overriding defaults, so it isn't required. But it does specify how coverage.py should behave.

Should it be coveragerc instead? Or coverage.rc? Opinions? Of course, .coveragerc files will still be recognized if a new default is used. I know this is a small point, but I'd like to follow the consensus if there is one.

Improving community is difficult. Getting 2500 people together without friction is impossible. Friction and offense will happen, the question is, what do we do about it? It seems to me there are two mindsets about how to improve a community.

The first mindset is, "Let's get rid of the assholes, and the people that are left will be a great community." I'll call this the shunning model: identify the Bad People, get rid of them, and you will have only Good People left.

The second mindset is, "We're all different, and we're going to make mistakes, so let's be thoughtful and educate each other." I'll call this the educating model: people are imperfect, but basically good, and if we can keep an eye on things and keep communicating, we can all improve.

When I look back at the aftermath of PyCon, I see a number of events that fit into the shunning model, and few that fit into the education model. This to me seems to be the heart of the problem.

We often talk about building an inclusive community, which usually means that women should be as welcome as men. I want it to also mean that people who make mistakes can be kept as members. Clearly, some people will be difficult enough that they won't be welcome, but most people who offend are good people who've made a mistake, not incorrigible assholes. I don't want a One Strike And You're Out community.

Let me tell you about my experiences at PyCon. I had at least three incidents of "community friction" during my time there:

• Friday at lunch, I sat across the table from a friend of mine. I made a joke that she found mean, and she told me so. I felt terrible, and apologized to her then, and again later when I saw her next.
• Saturday night, I was at the rowdy event that engendered a formal response from PyCon: a member was ejected and banned from PyCon. I was more than just an observer: I tried to talk to the member about what he had said. I also helped report it to the PyCon organizers.
• Monday morning, I was having breakfast with a group of people, both friends and new acquaintances, when someone used the word "retarded" to refer to some suboptimal technical detail. I don't like people using "retarded" as humor. I said nothing, but winked across the table to a friend to say, "yup, I heard it, I wish he wouldn't say that, but I'm not saying anything about it."

In incident #1, I was the offender, and I'm really glad I was educated instead of shunned.

In incident #2, I was the offended. The member in question has been banned. I wasn't part of deciding the sanctions, but am glad to see in his blog post that he is thoughtful about what happened.

In incident #3, I was the offended, but did nothing. If I had known the speaker better, I might have said, "I wish you wouldn't use that word that way," but it didn't seem right at the time.

Friction is inevitable. One of the great things about PyCon is that it is right at the boundary between being comfortable with old friends, and meeting new people. There are bound to be incidents. We have to accept that, and try hard to talk to each other to improve things for everyone.

Education is better than shunning.

But most attendees have no ribbons, and it occured to me we could have tokens for everyone. I thought of them as merit badges, but the more current terminology would be acheivements.

For example:

• I wrote a metaclass
• I avoided writing a metaclass!
• I introduced a friend to Guido
• I contributed to CPython
• I grok PyPy
• I taught a kid to program

And so on. Could be fun.

The workshop is hands-on: you start off standing at a type case, and with a few minutes of verbal instruction, you start putting type into a job stick:

I was familiar with the concepts of cold metal type, job sticks, California cases, and so on, but had never had a chance to try it myself. I was really pleased to be able to work with these little pieces of metal, and set actual lines of type.

You don't need to know the history of type to take the class, Keith explains what you need to know, and walks around gently guiding people to get them over rough spots.

I was having fun, and so went a little overboard. I wanted to use the fancy ligatures, so I included words like, "fluffy waffles," and when I saw that my type case had a "gg" ligature, I had to add "eggs." Then I discovered it had "zy" and "gy" ligatures, so I couldn't stop until I got "syzygy" in there!

Each student produced a few lines of type, then we all headed over to the press to assemble them together into a page:

Once we had all contributed our lines, Keith added larger blocks of iron and wood, known as "furniture" around it to hold it all in place, and locked it in with quoins.

A little discussion of paper, the mechanics of the press, then Keith rolls the press, and there's a printed sheet!

The first sheet is called a proof, because it's used to check the typesetting. The next step is to read the proof, an activity known as "proofreading"! One of the things I find fascinating about type is how history bleeds through into the present in the terminology and conventions. "Leading" makes much more visceral sense when you are holding a 6-pt thick bar of lead alloy, and place it between your rows of type.

Mistakes were identified, as were worn pieces of type. The form in the press was unlocked, and corrections made, by pulling out bits of type with a tweezers, inserting new ones, adjusting spacing, and so on. Then we each printed a sheet of our own.

When the printing was done, and the type had been cleaned, we each retrieved our lines of type, and put each tiny piece back into the proper compartment. Thinking about how long it took to find the type, set the type, adjust the type, print the type, and then clean up and put away the type, I am amazed anew that books, newspapers, and even encyclopedias ever got printed. This was very labor-intensive, dirty work. A few hours in a letterpress shop, and it is clearly industry.

After lunch, we each worked on a project of our own. I chose a quote from E.B. White:

Creation is in part merely the business of forgoing the great and small distractions.

I liked it not only for what it says, but because the words "great" and "small" could be used for a little type expression.

Here's where the old ways really seemed difficult! I wasn't sure what layout to use, and ended up changing my mind half-way through. So I had to move rows of metal chunks from one line to the next, and hope not to drop the whole thing.

Each line has to be completely packed tight with metal so that when the type is on the press, it will all be held tightly in place. This means that you need to find just the right thickness to fill the gaps, perhaps even slivers of brass to finish a tiny space.

I wanted an em-dash, but there wasn't one in my type case. We made one with a 36-pt piece of metal, spaced properly with yet more tiny chunks of metal. After dealing digitally with different kinds of spaces and dashes and leading, it was a new perspective to have to actually build it from pieces of metal.

To add to the complexity, the quote is set in 36-pt Centaur, but the word "small" is in 30-pt. I had to make up the 6-pt difference with strips of metal just as long as the word "small", but some above and some below to get the baseline right. I'd like to have used 24-pt for greater differentiation, but the next available size below 30 was 18. Another analog limitation.

When it was my turn for the press, Keith set up the form and locked it in, and I printed off a few dozen on gold paper:

Even before I printed it, there were things I wished I could improve about the layout, but time (and ability!) were short. The stars are there kind of as a distraction, but also because it's fun to use ornaments. But they are too low for the line: you can see in the photo, they are cast on a 36-pt body like the rest of the type, but they have a much lower baseline. I'm not even sure how I would have adjusted for that even if I had had time.

But I'm still very pleased with the result:

Keith made the day fun, he's friendly, passionate, knowledgable, and helpful. I highly recommend his class, it's a great way to see what letterpress is all about. It gives you a whole new perspective on type, and the technology that brought us to our current tools and techniques.