See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.

Towards comprehensible and maintainable code.

I am author of the Writing Idiomatic Python book.

Idiomatic Python is Pythonic code: code written in the way that the Python community has agreed it should be written.

Who decides this? Python developers, through the code that they write. Occasionally: Guido van Rossum.

The goals are: readability, maintainability and correctness.

"But I am a scientist, why should I write idiomatic code?" You want to be peer reviewed, right? If your code is eye-bleeding bad, you will get peer ignored.

"But I just write scripts." You program in Python.

"But I am coming from Java. Python programmers can still read all my class names that all have Factory in it, right?" Wrong.

Cognitive burden is the increased mental effort required to keep track of what is going on. Don't make me think.

Knuth said that our main task is not instructing computers, but explaining humans what a computer does.

Idiomatic code makes your intentions clear. It does not automatically make it correct. It let's others spot mistakes more easily.

Part of it, is staying up to date with changes in the language. Is there are better way to do it, with a new construct from the standard library or an extra package?

You are the most frequent reader of code you write. Have mercy on your future self. He may be a violent psychopath coming back to slap you in the past.

See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.

The title really should have been: a capitalistic and system conformant talk about encryption, but okay, let's talk about SSL.

The problem with programmers is that they think everything is a technical problem.

Let's talk about fraud. What makes credit card numbers secure? Nothing. They are just 16 digits. Some consider it safe to trust you when you know the last four digits.

We accept stolen credit cards. So the protocol is insecure. It is too easy to forget the bigger picture: the process itself is secure.

The 'lock' symbol stands for 'secure'. But you can use that symbol anywhere: it does not prove anything.

'It has encryption, so it is secure?' No, the used encryption system can be very insecure.

Remember why you encrypt. Do you really need SSL on your weblog?

Why do we encrypt traffic? Before Starbucks there was basically no public wifi. They made it possible for agents to attack idiots.

Encryption gives you protection against passive eavesdropping. For active eavesdropping, you need authentication, so people cannot impersonate you or the one you talk too.

Your user does not check fingerprints. Your user just thinks a lock symbol means it is secure.

Enter the Certificate Authorities (CAs). It is a distribution of the trust problem: you trust your browser, they trust certificate authorities, they trust their clients.

Let it be known that CAs are worthless for securing APIs.

Protecting APIs (non javascript) and servers:

• run your own CA
• issue certificates for 24 hours
• trust your own CA only
• screw revocations

You trust your own CA by distributing its certificate to everybody.

from requests import get
resp = get('https://api.yourserver.com/',
           verify='your/certificate.bundle')

"But my awesome AntiVirus syas your certificate is not trusted." -- a Windows user.

Revocations do not work in practice.

One shitty employee in one shitty CA is enough to break your security. (Crowd: this actually happened in the Netherlands with Diginotar.)

Soon: Certificate pinning? Changes are happening. Ideas are floating about.

Frack OpenSSL and question 'Best practices'. Not enough people have looked at the OpenSSL code. There is not enough knowledge among developers. Never, ever look at the source code of openssl; wrong defaults, patches. Apple's 'patches' are even worse.

Plan for failure. Plan for things going wrong. What happens when your user gets hacked? Food for thought: keyloggers are still a thing. What happens to your data? What happens to your company?

Security should not be your only defense.

@mitsuhiko at Twitter.

See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.

This is not only for Django sites, but may apply to other websites as well.

I have created http://ponycheckup.com and https://www.securedjango.com

queryset.filter(owner=self.request.user)

See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.

See the first talk introducing asyncio.

In asyncio there is no event class, no abstraction of what an event is. It runs callbacks which are put in a queue.

[Note: I am not going to type over the code examples, too easy to make typos.]

I/O handling APIs are in readyness style (tell us when you can start) or completion style (tell us when you are done). On Windows there are limits, so you may need to do it differently.

Polling: calculate a timeout, block for I/O, process I/O events (schedule callbacks), process timers (schedule callbacks), run pending callbacks.

Coroutines are generator functions, can also receive values. With the @asyncio.coroutine decorator I know I can use yield from on that function.

Futures represent a value which is not there yet. yield from can be used to wait for it. asyncio.wrap_future can be used to wrap a PEP-3148 Future into one of these.

f = Future()
f.set_result(...)  # or f.set_exception
yield from f  # wait until the result arrives

A Task is a unit on concurrent asynchronous work. It is actually a coroutine wrapped in a Future. It schedules callbacks using loop.call_soon. Use asyncio.async to turn a coroutine into a task.

Go read PEP-3156. Don't be afraid of looking under the hood in the source code.

@saghul on Twitter.

See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.