Instead of upgrading everything on my server, I'm just starting from scratch. From Ubuntu 16.04 to Ubuntu 19.04 and I also upgraded everything else in sight. One of them was uwsgi. I copied various user config files but for uwsgi things didn't very well. On the old server I had uwsgi version 2.0.12-debian and on the new one 2.0.18-debian. The uWSGI changelog is pretty hard to read but I sure don't see any mention of this.

You see, on SongSearch I have it so that Nginx talks to Django via a uWSGI socket. But the NodeJS server talks to Django via 127.0.0.1:PORT. So I need my uWSGI config to start both. Here was the old config:

[uwsgi]
plugins = python35
virtualenv = /var/lib/django/songsearch/venv
pythonpath = /var/lib/django/songsearch
user = django
uid = django
master = true
processes = 3
enable-threads = true
touch-reload = /var/lib/django/songsearch/uwsgi-reload.touch
http = 127.0.0.1:9090
module = songsearch.wsgi:application
env = LANG=en_US.utf8
env = LC_ALL=en_US.UTF-8
env = LC_LANG=en_US.UTF-8

(The only difference on the new server was the python37 plugin instead)

I start it and everything looks fine. No errors in the log files. And netstat looks like this:

# netstat -ntpl | grep 9090
tcp        0      0 127.0.0.1:9090          0.0.0.0:*               LISTEN      1855/uwsgi

But every time I try to curl localhost:9090 I kept getting curl: (52) Empty reply from server. Nothing in the log files! It seemed no matter what I tried I just couldn't talk to it over HTTP. No, I'm not a sysadmin. I'm just a hobbyist trying to stand up my little server with the tools and limited techniques I know but I was stumped.

The solution

After endless Googling for a resolution and trying all sorts of uwsgi commands directly, I somehow stumbled on the solution.

[uwsgi]
plugins = python35
virtualenv = /var/lib/django/songsearch/venv
pythonpath = /var/lib/django/songsearch
user = django
uid = django
master = true
processes = 3
enable-threads = true
touch-reload = /var/lib/django/songsearch/uwsgi-reload.touch
-http = 127.0.0.1:9090+http-socket = 127.0.0.1:9090
module = songsearch.wsgi:application
env = LANG=en_US.utf8
env = LC_ALL=en_US.UTF-8
env = LC_LANG=en_US.UTF-8

With this one subtle change, I can now curl localhost:9090and I still have the /var/run/uwsgi/app/songsearch/socket socket. So, yay!

I'm blogging about this in case someone else ever gets stuck in the same nasty surprise as me.

Also, I have to admit, I was fuming with rage from this frustration. It's really inspired me to revive the quest for an alternative to uwsgi because I'm not sure it's that great anymore. There are new alternatives such as gunicorn, gunicorn with Meinheld, bjoern etc.

The following post was originally published on OpenSource.com as part of a series on seven libraries that help solve common problems.

Imagine you have a "shapes" library. We have a Circle class, a Square class, etc.

A Circle has a radius, a Square has a side, and maybe Rectangle has height and width. The library already exists: we do not want to change it.

However, we do want to add an area calculation. If this was our library, we would just add an area method, so that we can call shape.area(), and not worry about what the shape is.

While it is possible to reach into a class and add a method, this is a bad idea: nobody expects their class to grow new methods, and things might break in weird ways.

Instead, the singledispatch function in functools can come to our rescue:

@singledispatch
def get_area(shape):
    raise NotImplementedError("cannot calculate area for unknown shape",
                              shape)

The "base" implementation for the get_area function just fails. This makes sure that if we get a new shape, we will cleanly fail instead of returning a nonsense result.

@get_area.register(Square)
def _get_area_square(shape):
    return shape.side ** 2
@get_area.register(Circle)
def _get_area_circle(shape):
    return math.pi * (shape.radius ** 2)

One nice thing about doing things this way is that if someone else writes a new shape that is intended to play well with our code, they can implement the get_area themselves:

from area_calculator import get_area

@attr.s(auto_attribs=True, frozen=True)
class Ellipse:
    horizontal_axis: float
    vertical_axis: float

@get_area.register(Ellipse)
def _get_area_ellipse(shape):
    return math.pi * shape.horizontal_axis * shape.vertical_axis

Callingget_area is straightforward:

print(get_area(shape))

This means we can change a function that has a long if isintance()/elif isinstance() chain to work this way, without changing the interface. The next time you are tempted to check if isinstance, try using singledispatch!

We have a new Early Access Program (EAP) version of PyCharm that can be now downloaded from our website.

New in the EAP

• Support was added for namespaces coming from packages. PyCharm now recognizes namespaces defined by other packages.
• Fixed a TensorFlow issue with its new version that wasn’t allowing PyCharm to recognize it properly as a library.
• Annotations were improved in a way that they won’t show unnecessary error messages for string literals.
• We fixed the position of the caret when an input is called for on the console. Before it was being shown at the beginning of the input call and now it is properly positioned at the end right next to where the input is about to be introduced.
• The autocomplete for methods inside classes now includes the ‘self’ parameter if smart enter is used.

Further Improvements

• The code inspection warning reprioritized the list of actions, giving a higher priority to quick fixes rather than run/debug actions.
• Option to customize scrollbar visibility from the appearance settings.
• And much more, check out the release notes for further details.

Interested?

Get the latest EAP build from our website. Alternatively, you can use the JetBrains Toolbox App to stay up to date throughout the entire EAP.

EAP Program Key Facts

• The EAP version of PyCharm Professional Version is free to use
• EAP build will expire after 30 days
• This is pre-release software, you may face stability issues and other rough edges
• You can install the EAP version alongside a stable version of PyCharm
• EAP versions of PyCharm report statistics by default, you can opt out by changing the settings in Preferences | Appearance & Behavior | System Settings | Data Sharing
• There’s an EAP version of the documentation as well

DjangoCon 2019 is happening next week Sept 22-27 in San Diego, and Microsoft is pleased to be supporting the conference as Gold sponsors this year. We will have some members from our Python team, our Azure Cloud Advocates, and the PostgreSQL team at the conference giving talks and at our booth.

Be sure to check out our talks from our team during the regular conference, all on Tuesday Sept 24th:

• Creating a containerized Django + React + PostgreSQL development environment by Dan Taylor at 2:20PM in Salon F-H
• Postgres Index types and where to find them by Louise Grandjonc at 3:10PM in Salon F-H
• Goodbye Print, Hello Debugger! by Nina Zakharenko at 5:30PM in Salon F-H

After the conference we’ll update this post with links to slides and content for the talks, so be sure to check back here!

If you are at the conference, come by our booth to meet the team and ask us your questions about Python, Django, and PostgreSQL in VS Code and Azure. If you cannot make it, or want more information after the conference, here are some helpful resources that cover a subset of what we’ll be sharing:

• Get Started with Python in Visual Studio Code
• Learn more about Python in Azure
• Hyperscale PostgreSQL in Azure
• Django in Visual Studio Code
• Django in Azure App Service

The post Come meet Microsoft at DjangoCon 2019 appeared first on Python.

On September 10, 2019 while I was in London, UK at the Python core dev sprints, I got a message from a user named "spacedrop" on Keybase. The message said I was being given 356.2904939 XLM as a surprise gift of "free Lumens worth $20.98 USD" from the Stellar Development Foundation. All of that screamed "cryptocurrency" which isn't my thing, so my initial reaction was this was some scam by someone who randomly messaged me on Keybase trying to get me to buy into some new cryptocurrency. But then I realized that Keybase wouldn't let a random person message me like that. Curious, I read the rest of the message and found a link to Keybase's "airdrop" announcement which explained that Keybase was actually facilitating the message. Trusting Keybase wasn't getting into anything nefarious,  that enticed me enough to dig a little deeper into Stellar and find their overview page which has the following summary:

Stellar is a multi-currency payment backend that tens of thousands of people  use every day. It’s decentralized, open-source, and developer-friendly,  so anyone can issue assets, settle payments, and trade.

Stellar  is a blockchain, but it works more like cash—Stellar is much faster and  cheaper than bitcoin, for example. And it uses far less electricity.

Okay, that sounds nice. But when I was poking around the web site and I found a code of conduct and a roadmap that both seemed reasonable, that's when I decided to dive into Stellar and I came out thinking that's it's actually a rather cool piece of technology for people to track "what they own ... and and what they want to do with what they own".

So this blog post is basically me writing down what I learned about Stellar and why I found it interesting from the perspective of trying to find a cheap, secure way to send remittance to the United States from Canada (which, spoiler alert, Stellar can't do for me yet, but the technology is there if someone would let me get CAD on to the Stellar network).

What is Stellar for?

I will go into more detail later, but to help motivate reading the rest of the blog post, I want to quickly outline what Stellar is. Basically it's a public ledger that tracks ownership of assets. Those assets do not need to be inherent to Stellar, and in fact a key part of Stellar is that 3rd-parties can provide their own assets to have managed on the network.

You can also trade assets on the network. Stellar lets you put out buy and sell orders on the network and the network will exchange these orders with assets as necessary at the best price for you. This is just like a stock market with buy and sell orders, but instead of stock certificates it's assets on the Stellar network. But one extra twist is that since Stellar lets anyone put assets on to the network, the network will do up to 6 different exchanges to try to get you the best value for your assets. For instance, if you're trying to buy spam with bacon, but people are only selling bacon for eggs and buying spam for eggs, the network will do the bacon -> eggs -> spam trade for you to get you the best result.

Now substitute "bacon" for "CAD" and "USD" for "spam" and you start to see how Stellar might be really handy for exchanging money around the world.

Lumens (yes, there's a digital currency)

To start discussing Stellar you need to know about lumens (or XLM for short). There's 100,000,000,000 lumens on the network since it went live, so there's no mining new ones like with Bitcoin. The smallest unit of lumens is called a stroop and it's 0.0000001 of a lumen (and they are named after stroopwafels which my wife and I like, and stroopwafels are Dutch which just makes the Pythonista in me smile 😊).

Now when I read that Stellar had lumens, I 🙄 like this was yet another cryptocurrency that people are just speculating with (which some people are), but when I began to read about what lumens are used for I realized it's actually an anti-spam mechanism and baseline asset to exchange for other things more than a play to make money from lumens themselves.

Accounts

Accounts on Stellar are a public key and a private seed. Nothing crazy, but also nothing terribly difficult to calculate either. So how does Stellar prevent people from creating a ton of accounts to spam the network?

By having a minimum account balance required to even create an account. Since lumens are the original asset on Stellar they are what you need to open an account (and keep it open). As of today it's 1 XLM which is about $0.07275 USD as I write this. In other words it is not a financial hardship to to require having a single lumen to open an account, but it also won't lead to everyone creating 1 billion accounts on their own either.

Trading

So now you have your account, how do you do something as simple as send or receive an asset? Once again, lumens are used as an anti-spam mechanism for trading.

Every change you want to make to the Stellar network is an operation. All the operations you want to do a single unit is a transaction (just like with databases). All the transactions that get resolved end up in a new version of the ledger which tracks the state of the network at that point in time.

Each transaction costs at least the base fee of 100 stroops per operation contained in that transaction. That way you can't flood the network with operations without having to at least pay a little bit for it.

And what exactly are you paying for? Well, there's a limit to how many new operations can occur on the Stellar network per ledger update. Protocol 11 made it so the network votes on what the maximum number of operations per ledger should be, and as of right now it's sitting at 1000 operations/ledger (if you look at any ledger like ledger 25923589 you will see max_tx_set_size and that shows the network's current operations/ledger rate). Even with ledgers resolving every 5 seconds, that still means there's limited capacity if the network gets backed up (i.e. it's about 200 operations/second). In those instances where there's not enough capacity there's surge pricing.

You specify the maximum base fee you're willing to pay when you create a transaction. An auction is held where your maximum base fee is offered to fund resolving your transaction. In the end, though, you end up paying only what was required for you to get your transaction resolved (e.g. you might offer to pay a total of 1000 stroops as a maximum base fee for your one operation, but if all it took was 150 stroops for your transaction to get resolved during surge pricing then that's all you end up paying).

So you're paying to prevent spam, and you're paying to potentially prioritize your transaction in case the network is backed up. Now currently the network is not at capacity so worrying about surge pricing isn't a big deal, but even if it did increase we're talking about miniscule amounts of XLM. With the price for 1 XLM that I quoted above, 100 stroop is $0.0000007275 USD, so even if you had to go up by several orders of magnitude to get your operation resolved it wouldn't exactly be expensive.

Inflation

One other interesting thing about lumens to help hit home the fact that they are more of an anti-spam mechanism and baseline asset everyone can agree to than an investment vehicle is the fact that the network has built-in inflation. The network automatically distributes 1% worth of lumens compared to the amount in circulation annually. The network also gives back all transaction fees that were collected. This is done to prevent speculating since it keeps lumens from becoming a scarce commodity and something you want to hoard as the value will systematically go down over time.

The way inflation and transaction fees are disbursed is via voting for an account to receive those funds which gets its proportion based on the amount of votes it got (which equates to the amount of lumens that voting account holds). Since an account must hold the votes of accounts in total of at least 0.05% of all lumens in circulation, people typically join an inflation pool. A popular one is https://pool.lumenaut.net/ which redistributes the lumens that the pool acquires back to those who voted for it in proportion to the amount of votes/lumens the account gave to the pool.

Basically there's no reason not to join an inflation pool. It's free lumens and it's easy to do. If you are on Keybase and were part of the airdrop, make sure to go into your lumens wallet and opt into one of the inflation pools as it was not done for you automatically.

Anchors (or what makes Stellar interesting)

So up to this point you're probably wondering how to heck remittance from Canada to the United States might work if everything is being done in lumens and I said they are not meant to act as investment vehicles. And the answer to that is assets and anchors.

Basically anchors join the network and offer tokens which represent assets that the anhor holds. The anchor can then send those assets as tokens to other accounts on the Stellar network, expressing the fact that an account owns those tokens representing that asset. While lumens is the asset we have talked about up until now, anything can be an asset on the network.

Let's say I run a bank and it acts as an anchor on the Stellar network that will generate tokens representing CAD. What that would mean is customers could withdraw CAD cash from their bank accounts and exchange them for CAD tokens on Stellar. My bank would hold the physical CAD in escrow to back the tokens in circulation. This allows people to then exchange their CAD tokens for real/fiat currency at my bank by sending the tokens to their account, whereby my bank would destroy the token so there isn't double-counting of the money in the world.

To take this bank analogy a little farther, think of physical cash as tokens, your wallet as your Stellar account, and the world of Canadian money as the Stellar network. When you withdraw money from the ATM, you are exchanging money in your bank account for a different format; in this case it's physical cash. You can then transact with it at stores, etc. And then eventually that physical cash comes back out of circulation when you deposit money into your bank account and becomes bits in some bank database.

And this is how anchors that back fiat currency work. For instance, AnchorUSD takes money in USD from you and then converts it 1:1 into a token on Stellar for you to send to whomever. It also lets you receive those USD tokens and then convert them back into USD money by destroying the token. Basically it's a gateway between the USD money and Stellar. This is also where lumens comes in, acting as a baseline asset everyone accepts and understands. That way you can transact in and out of XLM as necessary and still end up with what you want. In other words you can think of lumens as an intermediary asset that everyone understands. This also makes the value of lumens not critical if you do your end-to-end transaction at once as it will make lumens just a temporary part of the transaction (if it's even necessary to have it as an intermediary asset).

In order to prevent people from trusting any random anchor, Stellar has the concept of trustlines. Basically it's a way to say on the network, "we both agree that this token represents what the anchor says it does". That way you enter into an agreement with the anchor to avoid getting ripped off.

Why this interests me

When I realized that the Stellar network was set up so that it would be feasible for a CAD-equivalent of AnchorUSD to exist such that I could send family in the United States actual USD that they could deposit into their bank accounts from CAD money in my bank account, that got me excited. Typically I use TransferWise (if you choose to sign up to TransferWise, this is a referral link that gets me and the first couple of people who use it some money), but it takes a few days for the money to arrive and I have to go through some hoops  to get the cheapest fee with the fastest result by letting them log into my bank account to check I actually have the funds which has always bugged me from a security perspective.

Add on to that the fact that PayPal is about the only solution I know of for sending small amounts of money internationally – which happens regularly to me when I'm at a conference outside of Canada and the restaurant won't split the cheque – and you start to wonder why there aren't more potential solutions out there for sending money internationally in a fast, cheap manner.

And apparently I'm not the only one who thinks this: IBM has a service called World Wire built on the Stellar network specifically for moving money quickly and cheaply between banks. So now I'm just waiting for someone to set up a CAD-based anchor which acts as an Interac e-Transfer bridge between my Stellar account and my Canadian chequing account so I can send money to the United States cheaply and easily.

Interesting Links

Stellar - an open network for money

Stellar lets you hold, send, and swap digital versions of everyday currencies. Dozens of financial institutions issue assets and settle payments on Stellar.

an open network for moneyGithub IconTwitter IconKeybase IconReddit IconFacebook Icon

Stellar Dashboard

Stellar Dashboard.

Keybase Stellar Space Drop, 2 Billion Lumens for the World

Keybase is for keeping everyone’s chats and files safe, from families to communities to companies. MacOS, Windows, Linux, iPhone, and Android.

Lumenaut Pool

Lumenaut Pool. 100% payout, no fees. By the community, for the community.

StellarX

A user-friendly, peer-to-peer marketplace.

https://www.coinbase.com/earn/stellar/

(If you want to watch some videos from Coinbase and get some free lumens if you have a Coinbase account. If you don't have a Coinbase account and you want to sign up for one, you can use this referral link which will give me some extra lumens.)

Stellar News, Education, and Insights - Lumenauts.com

Lumenauts.com is your source for Stellar news, educational resources, and insights.

Michael BrinkLUMENAUTS.COMLUMENAUTS.COM

My Keybase Stellar account is:

GDZE4QWQLXHR6SWPOZ2ZUF6JWS3GBKEYQJDKWPZSD7JQTE2XP5GPS4KW

if you want a place to send XLM in order to experience that (I don't need more lumens so please don't view this as me begging for more, it's just that I didn't know anyone with a Stellar account when I started this so all I could do was just stare at my Keybase wallet until I got my free XLM from Coinbase and sent the assets to my own Keybase account).

Tools like error monitoring, crash reporting, and performance monitoring are tools to help you create a better user experience and are fast becoming crucial tools for web development and site reliability. But really what are they? And when do you need them?

You've built a cool web app or service, and you want to make sure your customers have a great experience.

You know I advocate for utilizing automated tests so you find bugs before your customers do. However, fast development lifecycles, and quickly reacting to customer needs is a good thing, and we all know that complete testing is not possible. That's why I firmly believe that site monitoring tools like logging, crash reporting, performance monitoring, etc are awesome for maintaining and improving user experience.

John-Daniel Trask, JD, the CEO of Raygun, agreed to come on the show and let me ask all my questions about this whole field.

Special Guest: John-Daniel Trask.

Sponsored By:

• Raygun: Detect, diagnose, and destroy Python errors that are affecting your customers. With smart Python error monitoring software from Raygun.com, you can be alerted to issues affecting your users the second they happen.

Support Test & Code - Python Testing & Development

1. Why does (inf + 0j)*1 evaluate to inf + nanj? - [22/2]
2. Pandas aggregate with dynamic column names - [13/5]
3. Convert dictionaries with list of values into a dataframe - [11/4]
4. Python print random line from file without repeat - [7/6]
5. What is the difference between "if x == True" and "if x:" - [7/3]
6. Why is the 'all' implementation slower than writing a for loop - [7/1]
7. Get Max value comparing multiple columns and return specific values - [6/8]
8. Counting most common combination of values in dataframe column - [6/5]
9. Convert 3d numpy array into a 2d numpy array (where contents are tuples) - [6/4]
10. Fill rows with consecutive values and above rows using pandas - [6/2]

Just a quick post here to let you know about a matplotlib feature I've only just found out about.

I expect most of my readers know how to produce a simple plot with a title using matplotlib:

plt.plot([1, 2, 3])
plt.title('Title here')

which gives this output:

I spent a while today playing around with special code (using plt.annotate) to put some text on the right-hand side of the title line - but found it really difficult to get the text in just the right location...until I found that you can do this with the plt.title function:

plt.plot([1, 2, 3])
plt.title('On the Right!', loc='right')

giving this:

You can probably guess how to put a title on the left - yup, it's loc='left'.

What makes things even better is that you can put multiple titles in different places:

plt.plot([1, 2, 3])
plt.title('Centre Title')
plt.title('RH title', loc='right')
plt.title('LH title', loc='left')

giving

I used this recently as part of some freelance work to produce graphs of air quality in Southampton. I had lots of graphs using data from different periods - one might be just for spring, or one just for early August - and I wanted to make it clear what date range was used for each graph. Putting the date range covered by each graph on the right-hand side of the title line made it very easy for the reader to see what data was used - and I did it with a simple bit of code like this:

plt.plot([1, 2, 3])
plt.title('Straight line graph')
plt.title('1st-5th June', loc='right', fontstyle='italic')

producing this:

(Note: you can pass arguments like fontstyle='italic' to any matplotlib function that produces text - things like title(), xlabel() and so on)

If you write software in Python, or depend on something that's in Python, this is for you.

Some of you are writing Python 2, or you still have software you depend on that is written in Python 2. January 1st, 2020, is the day that official support for Python 2 stops. So this is a fresh heads-up that you should really have a migration plan and start working on it, to move to Python 3. A lot of stuff you depend on already works on Python 3, and is even pledging to end Python 2 support in or before 2020. And it's easier than it's ever been to port your own code from 2 to 3.

You should probably upgrade to Python 3.7. If you want to test out 3.8, it has some changes in how it does warnings, and the first release candidate is out.

But, speaking of futureproofing:

Code authors move in and out of projects and companies. Six months or 18 months later, maybe you want to update and re-use, re-release or re-deploy code someone else wrote. Or you want your team to be able to reuse what you did after you leave, which means you need the code to run, and you need them to have the password so they can update stuff.

Have you written Python code that they have published as a package on the Python Package Index, pypi.org, so other people can use pip install to install it?

(And if you want to do that but don't know how? Check out this recently improved tutorial to help you do that.)

Publishing that package is a great way of making it so other people can run and deploy it, even within other parts of your organization.

But -- who actually has the keys to the castle? Who can upload a new version, or delete a version that has a problem?

You should probably make sure multiple people have either "owner" or "maintainer" privileges on the project on PyPI.

And you should review your project security history display, which lists sensitive events (such as "file removed from release version 1.0.1") in your PyPI user account and your PyPI project. We just added this display, so you can look at things that have happened in your user account or project, and check for signs someone's stolen your credentials.

And then how do you make it a little harder for vandals, spammers, and thieves to take over your account and upload malware or delete all the packages? Add two-factor auth for your login, like you would with your bank. Use an app on your phone to give you a six-digit code, or use a physical security device like a Yubikey.

And how do you make it easier to automate publishing new versions of your package, and make it safer to save your credential in the cloud? We've made it possible for you to create an "API token" where all it can do is upload, so you can use that instead of your PyPI password.

With well-tested Python 3 migration tools and new PyPI security features, now is a great moment to invest in robustness for Python software that you make or depend on.

[This blog post is kind of unwieldy, because it's about too many different things. I won't be publicizing it that much and instead will probably reuse text from it in more focused announcements elsewhere. But I'm publishing it here as a summary of my recent work, because management and communications for the projects above are what I've been working on recently for the Python Software Foundation. (A different kind of summary is on the Clients page for Changeset Consulting.)]

The post PyDev of the Week: Peter Farrell appeared first on The Mouse Vs. The Python.

As you might know, I’m a panelist on the weekly “Freelancers Show” podcast, which talks about the business of freelancing.

The good news: The same company that’s behind the Freelancers Show, Devchat.tv, is putting together a weekly podcast about Python, and I’m going to be on that, too! We’ll have a combination of discussion, interviews with interesting people in the Python community, and (friendly) debates over the current and future state of the language.

The better news: We’re looking for cohosts to participate in our panel discussion on a regular basis, say 2-4 times per month.

We’re looking for a diverse set of hosts, representing the breadth and width (and height, I guess) of the Python community — including skill levels, technical backgrounds, workplaces, and interests. You’ll also need a decent podcasting microphone. We’ll record weekly, on a day to be determined, at about 20:00 UTC for about 60-90 minutes.

If you’re talkative, articulate in English, interested in Python, able to commit to recording several times per month, and are willing to tolerate my jokes, then please be in touch, via e-mail (reuven@lerner.co.il) or Twitter (@reuvenmlerner)! We’re hoping to start in the coming month or two.

I should note that this podcast is not meant to replace the existing, and amazing, podcasts that already exist in the Python community! I listen to them (and occasionally appear on them, too), and have a lot of respect for the hosts of (for example) Talk Python to Me, Python Bytes, Python Init, and Test & Code. I hope that what we create will be complementary to their shows, and grow the Python community to an even larger degree.

Sound interesting? Let me know!

The post Looking for Python podcast co-hosts appeared first on Reuven Lerner.