Steven Troxler stroxler

Array-coercible shape inference

Status

This is a proposal for discussion. The semantics and scope below are intended as decisions rather than options; the remaining uncertainty is collected in the open questions at the end.

Delivery is split into three rough phases. Scalar-only projection establishes the construct and its integration first. Structural sequence projection then

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

Resources

Draft PEP Thread on typing-sig

General thoughts

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

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`

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

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.

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.

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]

	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

	# 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)