Forem: Sam Winter

8 Best Python Libraries for Algorithmic Trading

Sam Winter — Sat, 28 Nov 2020 16:49:01 +0000

Even as someone with significant experience in software engineering and some knowledge of data science, I underwent a learning curve when I started algorithmic trading. Feeling productive took some time. I found myself writing my own Bollinger bands, or scouring for trading calendars, or using each cryptocurrency exchange's idiosyncratic APIs instead of an abstraction over all of them. These are the Python libraries I wish I'd known when I began chasing alpha. They'll help you make money faster.

1. FinTA

FinTA (Financial Technical Analysis) implements over eighty trading indicators in Pandas. Unlike many other trading libraries, which try to do a bit of everything, FinTA only ingests dataframes and spits out trading indicators. Even the comments above each method are instructive, e.g., this comment annotating MACD. You'll likely see some indicators you don't even recognize, and the breadth of technical analysis encourages experimentation.

2. Zipline

Zipline is the best of the generalist trading libraries. It has almost 13k stars (see my article on using data to evaluate software packages here) and powers Quantopian, one of the most popular quant-finance communities, at least until Robinhood recently acquired it. Zipline allows you to ingest data from the command line (or a Jupyter notebook) and comes built-in with methods to facilitate writing complex strategies and backtesting them.

3. CCXT

CCXT (CryptoCurrency eXchange Trading) is a lifesaver if you programmatically trade cryptocurrency. No more will you have to write custom logic for each exchange. CCXT abstracts away differences between individual exchange APIs with a unified interface. It supports more than 120 exchanges. If you're not a Pythonist, you can even use the JavaScript and PHP implementations of CCXT (though you should get better taste in programming languages).

4. Freqtrade

Freqtrade is another crypto trading library that supports many exchanges. It facilitates backtesting, plotting, machine learning, performance status, reports, etc. You might be sighing at this point. How many cryptocurrency trading libraries does one algorithmic trading enthusiast need? What's amazing about Freqtrade is that you can control it with Telegram. That's right: you can henceforth DM your robot investment manager. Here are some of its awesome Telegram commands:

/status [table]: lists all open trades;
/profit: lists cumulative profit;
/forcesell <trade_id>|all: sells the given trade;
/performance: performance of each finished trade grouped by pair;
/balance: account balance per currency;
/daily <n>: profit or loss per day, over the last n days.

If you want to power up your Freqtrade trading bot and turn it into a Gundam ready to ravage financial markets on your behalf, check out Freqtrade Strategies, which is what its name suggests.

5. YFinance

If you've been trading for long, you've likely heard of Yahoo! Finance. YFinance allows you to reliably and efficiently download market data from Yahoo! Finance. The library arose from a dire need when Yahoo decommissioned their historical data API. The library's creator wrote a helpful tutorial here.

6. Backtrader

Backtrader is a popular Python framework for backtesting and trading that includes data feeds, resampling tools, trading calendars, etc. What sets Backtrader apart aside from its features and reliability is its active community and blog. Backtrader's community could fill a need given Quantopian's recent shutdown.

7. TensorTrade

TensorTrade is a framework for building trading algorithms that use deep reinforcement learning. It provides abstractions over numpy, pandas, gym, keras, and tensorflow to accelerate development. TensorTrade is still in beta, but it's quickly gaining traction and will likely become a mainstay in the quant community. Adam King, the creator of Tensor Trade, wrote an excellent tutorial.

8. Trump2Cash

I saved the memeiest library for last. Trump2Cash monitors Donald Trump's tweets. When he mentions publicly traded companies, it analyzes the tweet's sentiment and executes trades accordingly. The library even includes a utility to benchmark its historical performance. I'm not making any kind of recommendation, but the algorithm has been surprisingly successful.

Even supposing that Trump's ability to influence financial markets will soon wane, the source code is easily adaptable to other Twitter accounts. If you're interested in Twitter sentiment as a feature for a trading strategy, the repo is more than worth a look.

About Us

At Carrots we're building a hiring platform specifically for software engineers. You can connect your GitHub, Stack Overflow, and more to go beyond your resume. Our algorithm shows where you rank among world-class talent and surfaces your profile to top companies. Check out our Telegram channel for a live feed of developer jobs.

How to Evaluate NPM Packages

Sam Winter — Thu, 19 Nov 2020 17:28:45 +0000

I recently wrote an article on how to speed up React development, advising to, among other things, use packages instead of reinventing the wheel. You'll almost certainly want to use a modal library, for example, instead of building your own implementation. (I say "almost certainly" to include masochists and sadistic instructors.)

Here follows a qualification to my prior recommendation. Using third-party software carries risk. Malicious packages make the news almost every week. Millions of developer hours have been spent migrating from a deprecated library.

As an example, I'll compare several popular React component libraries along various mostly quantitative axes that assess risks to sustainability, performance, and security. I won't delve into subjective concerns such as APIs and UI, though these are certainly major factors in choosing a package. Even among this lofty tier of open source software, the difference in risk profiles is stark:

Longevity

Developers love stars. They're the de facto measure of a repository's quality. But they're an incomplete and at times misleading metric of potential to be evergreen (I couldn't resist the pun on Segment's component library). Other common indicators are how many repositories use this project, how many contributors there are, and which if any organizations sponsor the project. Here's how our component libraries stack up:

Package	Stars	Used By	Contributors	Corporate Sponsor
Chakra UI	12.4k	638	246
Evergreen	10.3k	1626	105	Segment
Antd	64.8k	5000+	1305
Base Web	5.6k	1012	177	Uber

All of these libraries are established, though Antd stands well above the rest. It's certainly not in danger of deprecation. A caveat to Antd's clear superiority is its age. It gained popularity long before these other libraries even had a package.json and hence acquired more stars, users, and so on. Its only major competitor for years was Material UI.

Before installing any package, I typically check its star history using Tim Qian's fantastic tool. Antd's advantage is clear:

Antd almost breaks the scale of our chart, so let's take a closer look at our newcomers:

Here we see drastically different trajectories. From star count alone, one might assume that Chakra UI and Evergreen are about equal in terms of adoption, but Chakra UI is clearly outstripping its competitors. All of these libraries received an initial burst of stars, yet only Chakra has sustained its growth for the past year.

Say you prioritize corporate sponsorship when evaluating packages and have narrowed your choice to Segment's Evergreen and Uber's Base Web. Evergreen might seem like a clear winner given its much higher star count and adoption. Where Evergreen falls short is in the distribution of its contributors and its commit frequency. Here's the activity from its top six contributors:

There have been few significant contributors to Evergreen outside of the top three developers. Even more alarming is that two of those three core contributors haven't been active in well over a year. Here's how Base Web compares:

Although Base Web also has a somewhat top-heavy distribution of contributions, it's more equal than Evergreen's, and its top contributors are still active. Meanwhile, the entire weight of Evergreen seems to rest on mshwery's shoulders.

The code frequency charts tell a similar story. Contributions to Base Web have been much more consistent:

Evergreen

Base Web

While libraries backed by successful tech companies tend to be more enduring (React itself is a prime example), they carry their own risks. Sometimes one or only a few engineers champion an open-source library within the company. When those advocates leave, the project can wither without institutional buy-in. More decentralized packages such as Antd and Chakra UI are resistant to political indifference.

Performance

Two pieces of software that do the same thing might radically differ in size. Moment.js is the most popular date manipulation library, with over twelve million downloads per week, yet it doesn't tree shake well and will add 300kB to your project. Day.js has almost the exact same API and is only 2kB. In fact, Moment.js now recommends using Day.js and other date libraries as alternatives.

Here's the cost of each component library according to the indispensable Bundlephobia:

Package	Minified Size	Tree Shakable	Side Effects	Dependencies
Chakra UI	363.3kB	Yes	No	44
Evergreen	795.3kB	Yes	No	17
Antd	1.2MB	Yes	Yes	45
Base Web	60.9kB	Yes	No	22

Antd is the obvious loser in terms of performance. By the way, Moment.js accounts for about 20% of its size. To download the entire Antd package would take almost seven seconds on emerging 3G. The fact that Antd has side effects is equally concerning. Side effects (code that performs some behavior external to its module) hinders treeshaking. A bundler cannot safely remove a module with side effects because it could have external effects that are required.

The data that Bundlephobia provides is instructive but incomplete. A package's impact on your application's size might be limited if much of that package is tree shaken. To accurately assess its size in the context of your application, use a tool like Webpack Bundle Analyzer, which generates a treemap visualization of bundle content:

Security

The most secure packages are popular, well maintained, and require minimal downstream dependencies. Even if a library has millions of downloads, its risk is higher when it doesn't meet these additional criteria (as when the original, inactive maintainer of event-stream gave publishing rights to someone who added a malicious downstream dependency). If a package is popular, there are more users to quickly identify a security issue; if it's well maintained, there are more developers to patch it; and if it has few dependencies, there's less risk in the first place.

While all of the component libraries we've examined are probably secure, the numerous dependencies of Chakra UI and Antd make them more vulnerable. After downloading a dependency, you should perform an audit with yarn audit or npm audit. These CLI commands identify security vulnerabilities in your packages and recommend patches. Ideally, you would also include yarn audit or npm audit in your continuous integration pipeline to check dependencies against known vulnerabilities with every pull request. yarn audit did in fact reveal a low-risk issue in Evergreen:

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ low           │ Denial of Service                                            │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ node-fetch                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=2.6.1 <3.0.0-beta.1|| >= 3.0.0-beta.9                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ evergreen-ui                                                 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ evergreen-ui > glamor > fbjs > isomorphic-fetch > node-fetch │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://www.npmjs.com/advisories/1556                        │
└───────────────┴──────────────────────────────────────────────────────────────┘

The above advisory was published on September 10th, and Evergreen's latest version was released on September 28th. The issue is likely inconsequential, but the fact that Evergreen did not fix it in that release or any subsequent commit might reflect poorly on their attention to security.

If software has eaten the world, then open-source software propels it forward. When evaluating packages, carefully select your chariot so that you find yourself astride a sleek, nimble unicorn instead of on your sofa on a Saturday night submitting pull requests for the ancient library upon which your entire application depends while praying for a review from a maintainer who's somewhere off the coast of Bermuda.

About Us

At Carrots we're building a hiring platform specifically for software engineers. You can connect your GitHub, Stack Overflow, and more to show off so much more than your resume. Our algorithm shows where you rank among world-class talent and surfaces your profile to top companies.

10 Ways to Speed Up React Development

Sam Winter — Mon, 16 Nov 2020 17:37:12 +0000

As much as I love writing React applications, I'd prefer not to. I'd rather have finished hours ago so I can spend time either on a beach outside my computer or in a videogame within it. In the spirit of laziness, here are ten ways to accelerate your React development.

1. Use a Framework

Frameworks remove degrees of freedom from the developer. You have fewer decisions because thousands of brilliant open-source developers have made them for you. At least nine times out of ten their decisions are better than yours would have been, unless you're Dan Abramov (if you are Dan Abramov, notice me, senpai). Follow the roadmap the framework sets forth to save time and write more consistent and robust code.

My favorite React framework is Next.js. You get SSR, built-in routing, automatic codesplitting, CSS-in-JS support, and more. You can even write lambdas that share business logic (such as types and validation) with your client-side code. If you host a Next.js app on Vercel, you can deploy a free, infinitely scalable application just by pushing to GitHub.

Other great frameworks include Gatsby.js and Remix.

Even if you decide not to use a framework, you should at least use a boilerplate generator such as create-react-app.

2. Use ESLint

I hope you're already using ESLint. There's no excuse to not use extremely configurable code that alerts you when you make mistakes. Two ESLint plugins are particularly helpful (and I'd argue essential) for React:

3. Use Prettier

Similarly to ESLint, you should use Prettier, an opinionated code formatter. Prettier integrates with most editors to automatically format your code on save, ensuring a consistent style. I'm all for our robot overlords taking away our freedom to get creative about trivialities.

4. Use AI-Driven Autocomplete

I hope that the first three suggestions were unsurprising. Using a framework, ESLint, and Prettier are par for the course if you're a JavaScript developer in 2020. This next suggestion is still a bit under the radar. It's my favorite developer tool to spring on friends to show I can still consort with JS hipsters.

Fully give in to the aforementioned robot overlords and use AI-driven autocomplete. My favorite so far is TabNine. You're probably rolling your eyes at the tech buzzwords, but try it and get back to me. You'll be impressed.

5. Superpower your CLI

Go a step beyond only empowering your JavaScript and plunge into the wonderful world of CLI tools. I recommend a few in particular:

Oh My Zsh: augment your Zsh configuration with thousands of helpful functions, helpers, plugins, themes, etc.
Scaffolder: painlessly generate boilerplate code.
ZSH-z: quickly jump to directories you've recently visited.

6. Use a React Component Library

Unless you work for a giant company that already has an internal component library, you'll almost certainly want to use one that's pre-built. I can no longer bear the thought of writing tomes of divs and ps instead of endlessly configurable Boxs and Texts. Admire the intuitive elegance of Chakra UI (taken from their website):

import * as React from "react";
import { Box, Image, Flex, Badge, Text } from "@chakra-ui/core";
import { MdStar } from "react-icons/md";

export default function Example() {
  return (
    <Box p="5" maxW="320px" borderWidth="1px">
      <Image borderRadius="md" src="https://bit.ly/2k1H1t6" />
      <Flex align="baseline" mt={2}>
        <Badge colorScheme="pink">Plus</Badge>
        <Text
          ml={2}
          textTransform="uppercase"
          fontSize="sm"
          fontWeight="bold"
          color="pink.800"
        >
          Verified &bull; Cape Town
        </Text>
      </Flex>
      <Text mt={2} fontSize="xl" fontWeight="semibold" lineHeight="short">
        Modern, Chic Penthouse with Mountain, City & Sea Views
      </Text>
      <Text mt={2}>$119/night</Text>
      <Flex mt={2} align="center">
        <Box as={MdStar} color="orange.400" />
        <Text ml={1} fontSize="sm">
          <b>4.84</b> (190)
        </Text>
      </Flex>
    </Box>
  );
}

Chakra UI is my favorite component library and is accelerating in popularity. Others include Rebass and Base Web.

7. Use a CSS-in-JS library

Even when using a component library, you might need to write CSS. It's like JavaScript's mostly inescapable stepsibling. Your best option is to write CSS in JavaScript, which allows for tighter scoping of styles to components, explicit dependencies, less cascading, and other benefits. A lot of the cool kids have started to use Linaria. Linaria doesn't carry the performance costs of other CSS-in-JS libraries because it extracts CSS files during buildtime, resulting in zero runtime.

Other devs enjoy Emotion, Styled Components, and JSS.

8. Use Storybook

Storybook allows you to quickly prototype React components in isolation from the app's business logic. You can mock different configurations of props to determine how your component will render. An underappreciated benefit of Storybook is that it enforces a clearly delineated architecture. I typically build as much of my application as possible within storybook, mocking increasingly complex components and even pages. By the time I start on the business logic, a wrapper component will be responsible only for providing props to my presentational ones. My smart components are completely separate from my dumb ones. If you haven't yet, read this classic article on smart versus dumb components.

9. Don't Write Your Own Forms

Learning to write forms in vanilla React is important. It forces the developer to recognize the difference between controlled and uncontrolled components, master state management, etc. When writing production code, however, you'll almost certainly want to use a library. A good form library will not only save you time, but it will also be less prone to bugs.

You may be thinking, "Aha, but I want to asynchronously validate user input," or, "What if one input depends on another?" No, there's a form library for these and 99% of all other use cases. I recommend Formik, but React Final Form and React Hook Form are other favorites.

10. Don't Reinvent the Wheel

React is a godsend to lazy programmers. All of the most complicated generalizable components are already written! If you find yourself writing a table, or an autocomplete component, or animation utilities, or if you're importing SVGs for icons, stop writing const Table = and search for a library. These are some of my favorites:

Framer Motion: for animations;
React Table: for tables;
React Icons: for icons;
React Draggable: for making elements draggable;
React Autosuggest: for autocomplete;
React Datepicker: for datepicking.

About Us

JavaScript WTF: Six of the Language’s Gravest Design Flaws

Sam Winter — Mon, 09 Nov 2020 17:49:18 +0000

Some of us have a perhaps misguided affection for JavaScript; others loathe the idiosyncrasies of a language created in ten days. Either way we're stuck with the parlance of web browsers, the idiom whose very name its creator called a "marketing scam." JavaScript makes us yell. It makes us laugh. Above all, it makes us cry a barbaric NaN over the mechanical keyboards of the world.

`==`

In the beginning was 1, and 1 was with true, and 1 == true.

Equality lies at the heart of logic, mathematics, and democratic society. JavaScript's equality operator (==) breaks the equivalence relation of mathematics in that it performs type coercion when evaluating equality. Yes, 1 is equal to 1 in JavaScript, but it's also equal to true and "1".

0 == 0; // => true
0 == 1; // => false
0 == "0"; // => true
0 == false; // => true

To rectify this original sin of unequal equality, JavaScript also offers the strict equality operator ===, which considers both type and value. Even the strict equality operator isn't without its quirks (or faults): NaN === NaN // => false. In JavaScript some equality operators are more equal than others.

`this`

A junior developer said, What is this?, pointing to his monitor with wide eyes; How could I answer the junior developer? … I do not know what it is anymore than he.

The JavaScript keyword this is much like English homograph "set." Its meanings are manifold and depend on context. There are as many ways to bind the value of this as there are days in the American programmer's work week, as much as we might wish there were fewer:

within a method, this is the calling object;
within a constructor, this is the newly created object;
in the global scope, this refers to the global object (or is undefined in strict mode);
in event handlers, this is the currentTarget of the event;
within a function bound with the call, apply, or bind methods of Function.prototype, this refers to the first argument of the binding method.

For a language that draws an unusually nuanced distinction between types of nothingness in null and undefined, the ambiguity of this is a curious choice. The global this in particular is utterly useless at best and often hazardous, hence its removal in strict mode.

`hasOwnProperty`

The runtime opened the object at once, while S. and JavaScript watched. It was stuffed with properties, and when it was opened two large prototypes fell out, tied up as you might tie up bundles of firewood. The runtime flinched in alarm. "Try higher up, higher up," said JavaScript, directing operations from above. The runtime, gathering up the properties in memory, obediently cleared everything out of the object to get to the properties up the chain. The runtime's memory was already half full of properties. "Oh, there’s been a lot of definition done," said JavaScript, nodding, "and this is only a small part of it. I keep the larger part of what I have here up the chain."

JavaScript is the only popular programming language using prototypal inheritance, often contrasted with classical or class-based inheritance. While prototypal inheritance isn't as classy as its counterpart, it's a more powerful paradigm. One can easily build classical inheritance from prototypal, and prototypal inheritance is more naturally suited to composition over inheritance.

Unfortunately, the for in loop unexpectedly traverses an object's entire prototype chain, not only the object itself. If one were to iterate over the properties of a Goomba, the minutiae of the Nintendo Corporation would follow (provided these minute Nintendoan properties weren't defined with Object.defineProperty, added in ES5). To iterate through a Goomba and a Goomba alone, one need check if goomba.hasOwnProperty(property):

for (const property in goomba) {
  if (goomba.hasOwnProperty(property)) {
    console.log(property);
  }
}

hasOwnProperty isn't an original sin like == or a source of bewilderment like this. It's a guardrail to unintuitive and usually unwanted behavior.

`typeof`

There is no variable one can declare that is not filled with angst and ambivalence, that is not, in one of those values, the mighty typeof an object.

The operator typeof is the most worthless feature in all of JavaScript. With the precision of a software developer returning from a long vacation and trying to determine where she left off, typeof's return values are often misleading and uninformative:

typeof {}; // => object
typeof null; // => object
typeof []; // => object
typeof /abc/; // => object
typeof Math; // => object
typeof new String("abc"); // => object
typeof new Date(); // => object
typeof new Boolean(false); // => object
typeof new Number(1); // => object
typeof new Function(); // => function ;)

The highest purpose of typeof is to check whether a variable is undefined, e.g., typeof actuallyNotAnObject === "undefined". To reference the variable otherwise would result in a ReferenceError.

`eval`

Then, with inviolate curve, forsake our eyes

As apparitional as sails that cross

Some string of text to be evaled away;

- Till with untrusted code ourselves betray ...

The eval function is JavaScript's four-letter word. It executes any string of code passed to it with the privileges of the caller. When a malicious party has influenced that string, eval poses a tremendous security risk. It's not even performant given that it has to invoke the JavaScript interpreter—particularly expensive when interfacing with machine code as in variable lookup.

JavaScript developers may not realize that they're using eval "under the hood" when they pass a string of code as an event-listener callback or as an argument to setTimeout or setInterval. Barring build tools and the onanism of metaprogrammers, code ought to be written as code, not strings.

`;`

The Semicolon has not left me and I don't believe it will leave me so soon; but I no longer have to bear it, it is no longer an illness or a passing fit: it is I.

Like a well-intentioned simpleton under cover of night, the JavaScript parser covertly inserts semicolons when it encounters syntactic errors due to missing semicolons, often inadvertently changing the code's behavior. (The official rules of automatic semicolon insertion read like GPT-3's attempt at computer-scientific legalese.)

The parser papers over what ought to be errors rather than constraining syntax by design. This degree of freedom causes the semicolon-forgetful JavaScript developer's code to break in surprising ways. The developer only discovers this sort of nerdwar-precipitating bug at runtime, if at all:

clearMenus()
!isActive && $parent.toggleClass("open")

Semicolons are tedious; they lack understated beauty; yet with parser so devious, semicolons are one's duty.

About Us

25 Best GitHub Repos for Python Developers

Sam Winter — Fri, 30 Oct 2020 16:38:17 +0000

According to StackOverflow's 2020 Developer Survey, Python is one of the most loved languages in the world behind only Rust and TypeScript. Even more amazingly, Python is the language developers most want to try at their jobs. If you're one of the lucky many who use Python and want to up their game or the other lucky many who want to learn Python, you're come to the right place. These are 25 of the best Python repositories on GitHub:

'Awesome' Python Lists:

Awesome Python: a curated list of awesome Python frameworks, libraries, software and resources.
Fucking Awesome Python: for when you want a curated list of Python frameworks, libraries, software and resources that's even more awesome.
Awesome Python Applications: almost 400 open-source Python applications arranged by topic, with links to repositories, docs, and more, generated from structured data using apatite.
Awesome Pytorch: libraries related to Pytorch, the famous machine learning framework for tensors and dynamic neural networks.
Awesome Asyncio: a carefully curated list of awesome Python asyncio frameworks, libraries, software and resources.
Awesome Jupyter: a curated list of awesome Jupyter projects, libraries and resources. Jupyter allows you to create and share Python documents that contain live code, equations, visualizations, text, and more.
Awesome Python Books: the best directory for books related to Python!

Books

Hitchhiker's Guide to Python: a best practice handbook to the installation, configuration, and usage of Python on a daily basis, including pip, numpy, virtualenv, and more.
Byte of Python: a tutorial for beginners; you only need know how to save a text file.
Cosmic Python: pythonic application architecture patterns for managing complexity; a free O'Reilly book!
Python Machine Learning: this repo includes code notebooks for the classic machine learning textbook.

Interview Questions

Cracking the Coding Interview Solutions: solutions in Python to the classic Cracking the Coding Interview; try not to cheat!
Interactive Coding Challenges in Python([]): 120+ continually updated, interactive, and test-driven coding challenges, with Anki flashcards.
Python Interview Questions: questions you're likely to come across during an interview for a Python job.
Even More Python Interview Questions: when you need 300+ more questions than the ones above.

Data Structures and Algorithms

Pythonic Data Structures and Algorithms: minimal and clean implementations of data structures and algorithms in Python 3 (18k+ stars)!
Udemy's Algorithms, Data Structures, and Interviews Course: this repo contains notebooks accompanying the course to help you prepare for your interviews.
Algorithms in Python: implementations of a few algorithms and data structures for fun and profit!

Python Resources

GitHub's Python Trending List: trending Python GitHub repositories.
PEP 8—Python Style Guide Checker: this tool checks your Python code against PEP 8 style conventions.
Google Style Guides: Google's recommendations for Pythonic style.
Python Enhancement Proposals: the official index of Python Enhancement Proposals or PEPs.

Learn Python

Python Koans: an interactive tutorial for learning Python by making tests pass (and a good primer on Test-Driven Development).
Project-Based Learning: a list of programming tutorials that are project-oriented, including building web scrapers, applications, bots, etc.
Learn Python 3 Through Jupyter Notebooks: a collection of interactive Jupyter notebooks that teach you Python 3.

Originally published at Carrots.

Tucker Triggs' list of JavaScript repos shamelessly inspired this post.