Skip to content

Instantly share code, notes, and snippets.

@dmtucker
dmtucker / vehicle-collision-eap.md
Created December 27, 2016 05:22
Vehicle Collision EAP

Vehicle Collision EAP

  1. Stay calm.

    • Do NOT accuse anyone.
    • Do NOT admit fault.
  2. Cooperate as much as you can. No one enjoys being involved in a collision.

@dmtucker
dmtucker / keybase.md
Created May 28, 2017 06:32
Keybase PSA

Keybase proof

I hereby claim:

  • I am dmtucker on github.
  • I am dmtucker (https://keybase.io/dmtucker) on keybase.
  • I have a public key whose fingerprint is A3E0 EF6C ECB3 3C34 2AA6 EC7C 5508 153A 6E7F C5FB

To claim this, I am signing this object:

  • setuptools builds distributions from source code.
  • pip (un)installs distributions (optionally, from PyPI).
    • twine publishes distributions to PyPI.
  • pytest tests installed distributions.
#!/usr/bin/env python3
ROMAN_LEGEND = {
'I': 1,
'V': 5,
'X': 10,
'L': 50,
'C': 100,
'D': 500,
import math
def apy(apr, periods=12):
return (((apr / periods) + 1) ** periods) - 1
def apr(apy, periods=12):
return (((apy + 1) ** (1 / periods)) - 1) * periods
why doesn't it make sense to mix strings and bytes in path components with posixpath.join? this Q is really only for py2 since 3 does away with implicit conversions, but the unicode could be encoded and the join would succeed. even if that results in a multi-encoding str, I've been told, that's ok in POSIX
import os
import py
def _relpath(path, *, relto):
# TODO py35+ commonpath = os.path.commonpath([path, relto])
commonpath = str(py.path.local(path).common(py.path.local(relto)))
def _commonpath_to(_path):
return _path[len(commonpath):].strip(os.path.sep)
$ python3 sep.py
different: cp037 b'a'
different: cp273 b'a'
different: cp424 b'a'
different: cp500 b'a'
different: cp875 b'a'
different: cp1026 b'a'
different: cp1140 b'a'
untested: cp65001
different: utf_32 b'\xff\xfe\x00\x00/\x00\x00\x00'
@dmtucker
dmtucker / 1.17
Last active April 25, 2020 04:07
What's up with Python 1.17 in the PyPI stats database?

say we claim support for >=1, <3

  • 1.0 is the first supported version.
    • if this isn't tested, features from later versions may be depended on that break compatibility with this version.
  • 1.x adds to it.
    • test the latest version available to detect new features that collide (e.g. variables named async are fine in python 3.6 but async becomes a keyword in python 3.7).
      • only the latest version needs to be tested because features cannot be removed without a major version bump.
    • if something breaks, either
      • a new feature collided with existing code
      • upstream did not follow semver and broke compatibility
  • existing code uses upstream code that is not part of the public API