jasonrdsouza

def getchar():
   #Returns a single character from standard input
   import tty, termios, sys
   fd = sys.stdin.fileno()
   old_settings = termios.tcgetattr(fd)
   try:
      tty.setraw(sys.stdin.fileno())
      ch = sys.stdin.read(1)
   finally:
      termios.tcsetattr(fd, termios.TCSADRAIN, old_settings)

lambdamusic

import string

def make_color_tuple( color ):
    """
    turn something like "#000000" into 0,0,0
    or "#FFFFFF into "255,255,255"
    """
    R = color[1:3]
    G = color[3:5]
    B = color[5:7]

thriveth

CB_color_cycle = ['#377eb8', '#ff7f00', '#4daf4a',
                  '#f781bf', '#a65628', '#984ea3',
                  '#999999', '#e41a1c', '#dede00']

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

adamnew123456

# This is free and unencumbered software released into the public domain.
# 
# Anyone is free to copy, modify, publish, use, compile, sell, or
# distribute this software, either in source code form or as a compiled
# binary, for any purpose, commercial or non-commercial, and by any
# means.
# 
# In jurisdictions that recognize copyright laws, the author or authors
# of this software dedicate any and all copyright interest in the
# software to the public domain. We make this dedication for the benefit

bharadwaj-raju

fileserver.py

Credit to bones7456.

Instructions

Change values in settings.py, place it in the same directory as fileserver.py then run python2 fileserver.py

amarao

#!/usr/bin/env python
import argparse


def main(command_line=None):
    parser = argparse.ArgumentParser('Blame Praise app')
    parser.add_argument(
        '--debug',
        action='store_true',
        help='Print debug info'

scragly

Learning discord.py

This guide assumes your version of discord.py is updated to at least v1.0 or greater.
You can check your version with pip show discord.py.

Show Contents

• Required Knowledge
• Essential References
• Creating a Discord Bot Account

qoomon

Conventional Commit Messages

See how a minor change to your commit message style can make a difference.

Tip

Take a look at git-conventional-commits , a CLI util to ensure these conventions, determine version and generate changelogs

Commit Message Formats

Default

Zekfad

Quick examples

• feat: new feature
• fix(scope): bug in scope
• feat!: breaking change / feat(scope)!: rework API
• chore(deps): update dependencies

Commit types

• build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
• ci: Changes to CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
• chore: Changes which doesn't change source code or tests e.g. changes to the build process, auxiliary tools, libraries