stroxler

Web: DNS

A quick introduction to DNS

DNS at a glance

In one sentence, I’d say that DNS is a chain-of-trust system for configuring

stroxler

Resources

Draft PEP Thread on typing-sig

General thoughts

I think existence, but not use, of extra fields should be the default

stroxler

About this guide

This is a very rough set of notes taken in 2022 to help engineers understand the logic as well as the nontrivial Haskell concepts (e.g. GHC extensions) embodied in that logic.

It is not an official guide from the Duckling authors, and there are likely at least a few errors.

These notes only cover the core Duckling engine, not any logic specific to a specific Dimension. Most dimensions are relatively straightforward, but some are quite complicated - particularly Time - and these notes do not cover those.

The layers we interact with: debug and analyze

stroxler

This gist is a collection of all the easy-to-find online resources for using typed python as of 2022/01. I collected these notes for two reasons:

• As an aside in an extensive python-dev typing discussion, Guido mentioned that it would be helpful
• There’s an active but very slow-moving effort to write official python type system docs in python/typing, and I figured having an easy to skim list of the best existing discussions would be handy.

The official documentation

stroxler

class Dog:
    def __init__(self, color: str) -> None:
        self.color = color
    def __call__(self, command: str) -> None:
        print("Dog will now " + command)


inspect.signature(Dog("brown")) == inspect.signature(Dog)          # False
inspect.signature(Dog("brown")) == inspect.signature_of_type(Dog)  # True

stroxler

Considering tweaks to parentheses rules for PEP 677

This gist contains

• A description of some major concerns I have about adding -> as a legal top-level operator in type expressions.
• Discussion of solutions that involve requiring parentheses around callable types.
• Two files of examples of proposed alternative syntax
  • First, a comparison of the current syntax to requiring parentheses both around the args list (as we do now) and around the entire type.

stroxler

# A quick example to illustrate the two syntaxes
def f(x: str, y: int) -> bool: ...
    

f: ((str, int) -> bool)    # full parentheses syntax
f: (str, int) -> bool      # args only parentheses

    
# Now, some samples from typeshed (I abbreviated a few args lists so that it's easier to find the relevant part)

stroxler

1. We can't naively union a callable type with another type:

union_of_callables: (int) -> str | (bool) -> str  # Syntax error!

# Needs extra parens; Not intuitive or user-friendly.
union_of_callable2: ((int) -> str) | ((bool) -> str)

# Simpler and can be easily split into multiple lines, as Никита mentioned.

stroxler

Some existing Callable types from github

Using the most restrictive full-stub syntax, here's how we'd express a few Callable types:

# from functools.pyi
f0: Callable[[_T1, _T2], S)
f0: (t1: _T1, t2: _T2, /) -> S

# from shapeflow/api.py
f1: Callable[[Optional[int], np.ndarray], stream_image]