Skip to content

Instantly share code, notes, and snippets.

@mdrachuk
mdrachuk / transcribe.py
Created March 21, 2021 15:45
Transcribing text from mp3 audio files with timestamps.
from functools import reduce
from pathlib import Path
import speech_recognition as sr
from pydub import AudioSegment
def transcribe(wav: Path, start_at=0, iteration=10):
"""Use start_at when transcription hangs and does not work."""
transcription_path = wav.with_suffix('.txt')
@mdrachuk
mdrachuk / tz.py
Last active September 17, 2019 12:52
An immutable tzinfo implementation with *nice* offsets: utc[+2:00], utc[+1:30].
"""TimeZone is an immutable (frozen) tzinfo implementation with *nice* offsets: utc[+2:00], utc[+1:30]."""
__author__ = "Misha Drachuk"
__license__ = "MIT"
from dataclasses import dataclass, field
from datetime import timezone, timedelta, tzinfo, datetime
from math import copysign
@mdrachuk
mdrachuk / zen.md
Last active September 10, 2019 12:23
The Zen of Python, by Tim Peters

The Zen of Python (PEP 20)

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
@mdrachuk
mdrachuk / bloch.md
Last active September 10, 2019 12:23
API Design by J. Bloch
  1. All programmers are API designers. Good programs are modular, and intermodular boundaries define APIs. Good modules get reused.
  2. APIs can be among your greatest assets or liabilities. Good APIs create long-term customers; bad ones create long-term support nightmares.
  3. Public APIs, like diamonds, are forever. You have one chance to get it right so give it your best.
  4. APIs should be easy to use and hard to misuse. It should be easy to do simple things; possible to do complex things; and impossible, or at least difficult, to do wrong things.
  5. APIs should be self-documenting: It should rarely require documentation to read code written to a good API. In fact, it should rarely require documentation to write it.
  6. When designing an API, first gather requirements--with a healthy degree of skepticism. People often provide solutions; it's your job to ferret out the underlying problems and find the best solutions.
  7. Structure requirements as use-cases: they are the yardstick agai