Sublime Text is not an IDE nor it pretends to be, but its powerful plugin system has allowed the community to come up with clever ways to have some IDE capabilities.
I’ve been using ST4 in its beta releases exclusively for some time and arrived at a setup that I enjoy, hopefully you will to.
I will update this post with any developments in the tools and setup.
And just like that, Python 2.7 has reached end-of-life, and your Python 2.7 app has officially become a problem.
Where do you even start? Everything will need to change!
I’ve been there and it’s not great. It’s not just the changes to the code, there’s many other factors to keep in mind while upgrading and a lot of potential problems caused by subtle and not so subtle differences in Python itself and your dependencies.
I had to go through this process recently for a 140k lines of code app first and a couple times more for smaller services and, as one does, I worked out a system which I now present to you in guide form.
You will not find an exhaustive list of syntax differences between Python 2 and 3 in this guide, if that’s what you’re looking for I recommend the free Supporting Python 3 book. This is a pragmatic, hands-on workflow to upgrade your app to Python 3 that worked for me, hopefully it will help you too.
It’s just a fact of life, as code grows eventually you will need to start adding mocks to your test suite. What started as a cute little two class project is now talking to external services and you cannot test it comfortably anymore.
That’s why Python ships with
unittest.mock, a powerful part of the standard library for stubbing dependencies and mocking side effects.
unittest.mockis not particularly intuitive.
I’ve found myself many times wondering why my go-to recipe does not work for a particular case, so I’ve put together this cheatsheet to help myself and others get mocks working quickly.
This is the second part of a two part series on coroutine patterns in asyncio, to fully benefit from this article please read the first installment: Asyncio Coroutine Patterns: Beyond await
In the first part of this series we concluded that asyncio is awesome, coroutines are awesome and our code is awesome. But sometimes the outside world is not as awesome and we have to deal with it.
Now, for this second part of the series, I’ll run over the options asyncio gives us to handle errors when using these patterns and cancelling tasks so as to make our asynchronous systems robust and performant.
If you are really new to asyncio I recommend having a read through my very first article on the subject, Asyncio for the Working Python Developer, before diving into this series.
Asyncio, the concurrent Python programmer’s dream, write borderline synchronous code and let Python work out the rest, it’s
import antigravityall over again…
Except it isn’t quite there yet, concurrent programming is hard and while coroutines allow us to avoid callback hell it can only get you so far, you still need to think about creating tasks, retrieving results and graceful handling of errors. Sad face.
Good news is all of that is possible in asyncio. Bad news is it’s not always immediately obvious what wrong and how to fix it. Here are a few patterns I’ve noticed while working with asyncio.
I remember distinctly the moment where I thought, “Wow, that’s slow, I bet if could parallelise these calls it would just fly!” and then, about three days later, I looked at my code and just didn’t recognize it, it was an unreadable mash up of calls to threading and process library functions.
Then I found asyncio, and everything changed.
Hey, Django dev, come here for a sec!
I heard you’re on Rails now, looking for some quick answers?
Yeah, I’m your man, got them right here.
You are seasoned Django developer.
You are master of the models. Ruler of the views. King of the templates.
But fate has brought you to Rails now, and you feel clumsy, slow, googling every step of the way. You’re asking yourself how do I Django in Rails?