Thanks, this could be a useful addition to the type system! However, I'm not clear yet on exactly what you're proposing: some questions below. El jue, 10 feb 2022 a las 9:40, Patrick Arminio () escribió:

Hi everyone!

Recently I felt the need for a `Pick` type in Python. The name is "inspired" from TypeScript's `Pick` type (see https://www.typescriptlang.org/docs/handbook/utility-types.html#picktype-key... ).

Here's an example of how it work, let' say that we have a `User` model that represents a table in a database and we have a `fetch_user` function that returns a `User` with only `id` and `name`.

Here's how the code could look like:

```python from typing import Pick

class User: id: int name: str password: str email: str

def fetch_user(name: str) -> Pick[User, "id" | "name"]: return fetch_from_db("user", name=name, fields=["id", "name"])

What would this mean exactly? In TypeScript it's easier because (simplifying a bit) everything is a TypedDict, but here it looks like you're using a concrete class, not a TypedDict. How would you write the return type without Pick?

```

Note: I'm making use of the union syntax on strings, which I don't think it is supported yet. I've done so in order to keep the code a bit simpler.

That might be a hard sell because the way things currently are, it should

mean adding str.__or__ everywhere, even outside of a typing context.

I wanted to see what's the feeling for a feature like this. I think it might be quite useful in the scenario I described above, I guess it could make some ORM's code more type safe 😊

I can try to write a PEP for this and if anyone is interested in helping I'd happy to work with you 😊 _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com

I like the overall idea, it relates to code I have written in the past. 2 questions: 1. Why stop at “Pick” ? I wasn’t aware of https://www.typescriptlang.org/docs/handbook/utility-types.html but it seems there are other similar constructs that could be useful (ex: “Omit” is actually the opposite of “Pick”). 2. Are there any actual ORMs or forms/data/json validation frameworks that could be plugged into the code examples you’ve provided ? S. On 10 Feb 2022 at 18:40:11, Patrick Arminio wrote:

Hi everyone!

Recently I felt the need for a `Pick` type in Python. The name is "inspired" from TypeScript's `Pick` type (see https://www.typescriptlang.org/docs/handbook/utility-types.html#picktype-key... ).

Here's an example of how it work, let' say that we have a `User` model that represents a table in a database and we have a `fetch_user` function that returns a `User` with only `id` and `name`.

Here's how the code could look like:

```python from typing import Pick

class User: id: int name: str password: str email: str

def fetch_user(name: str) -> Pick[User, "id" | "name"]: return fetch_from_db("user", name=name, fields=["id", "name"])

```

Note: I'm making use of the union syntax on strings, which I don't think it is supported yet. I've done so in order to keep the code a bit simpler.

I wanted to see what's the feeling for a feature like this. I think it might be quite useful in the scenario I described above, I guess it could make some ORM's code more type safe 😊

I can try to write a PEP for this and if anyone is interested in helping I'd happy to work with you 😊 _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: sf@fermigier.com

-- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Co-Founder & Co-Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Co-Founder & Chairman, Association Professionnelle Européenne du Logiciel Libre (APELL) - https://www.apell.info/ Co-Founder & Spokesperson, European Cloud Industrial Alliance (EUCLIDIA) - https://www.euclidia.eu/ Founder, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/

I like the idea. 1. This would presumably generate a new (data)class, which would contain a subset of fields from another (data)class. You didn't decorate `User` with `@dataclass`; was this omission intentional? 2. It would be useful to show how such a function would return such a `Pick(...)` value. Presumably you would create a type alias above the function, then use it to initialize the instance with `id` and `name` parameters? 3. Do you think this could be made to work with `TypedDict` as well? 4. Something similiar I've developed, which I would be happy to replace or supplement with Pick: https://github.com/fondat/fondat-core/blob/main/fondat/data.py#L88. Paul On Thu, 2022-02-10 at 17:40 +0000, Patrick Arminio wrote:

Hi everyone!

Recently I felt the need for a `Pick` type in Python. The name is "inspired" from TypeScript's `Pick` type (see

https://www.typescriptlang.org/docs/handbook/utility-types.html#picktype-key...

).

Here's an example of how it work, let' say that we have a `User` model that represents a table in a database and we have a `fetch_user` function that returns a `User` with only `id` and `name`.

Here's how the code could look like:

```python from typing import Pick

class User:     id: int     name: str     password: str     email: str

def fetch_user(name: str) -> Pick[User, "id" | "name"]:     return fetch_from_db("user", name=name, fields=["id", "name"])

```

Note: I'm making use of the union syntax on strings, which I don't think it is supported yet. I've done so in order to keep the code a bit simpler.

I wanted to see what's the feeling for a feature like this. I think it might be quite useful in the scenario I described above, I guess it could make some ORM's code more type safe 😊

I can try to write a PEP for this and if anyone is interested in helping I'd happy to work with you 😊 _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: pbryan@anode.ca

(1) On 2/10/22 12:40 PM, Patrick Arminio wrote:

Recently I felt the need for a `Pick` type in Python. The name is "inspired" from TypeScript's `Pick` type (see https://www.typescriptlang.org/docs/handbook/utility-types.html#picktype-key...).

Very interesting. I imagine you could apply a Pick[] type constructor to a {NamedTuple, @dataclass, TypedDict, Protocol}-based type in order to get a new type of the same flavor. (So if you had a Movie type that was a TypedDict, a Pick[] applied to Movie would generate a new *TypedDict* type.) (2) Your example of using Pick[] applied to a Django Model class I also find to be inspiring. In that case Pick[] is being applied to a plain-old-object type and presumably returns a Protocol-based type. As a Django user I'm fascinated by the ability to prevent extra database queries using the type system in the way described here. (3a)

Note: I'm making use of the union syntax on strings, which I don't think it is supported yet. I've done so in order to keep the code a bit simpler.

That might be a hard sell because the way things currently are, it should mean adding str.__or__ everywhere, even outside of a typing context.

Yes, I guess we could leverage Literal for the time being :)

I'd advocate instead having a syntax similar to how Callable[] takes argument types in a bracketed list. So you might write: ``` Pick[User, ["id", "name"]] ``` (However I could also see the argument that `Pick[User, Literal["id", "name"]]` would be more consistent with the current syntax, even as it introduces redundant always-the-same "Literal" noise.) (3b) The preceding syntax feels natural to me if you were to additionally support the kind of metaprogramming you suggested here:

```python def derive_datacls( cls_name: str, dataclass: T, *, include: set[Literal[str]] = None, exclude: set[str] = None, append: Iterable[Union[tuple[str, type], tuple[str, type, dataclasses.Field]]] = None, optional: Union[set[str], bool] = False, **kwargs, ) -> Pick[T, include]: ```

and in the future it could also use `Omit` :)

However I will note that you probably want to wrap "include" in some kind of bracketed syntax rather than leaving it as a bare string. The usage here looks like the use of a Dependent Type, while could be pretty tricky to specify and introduce... You might consider leaving that kind of metaprogramming to a separate future PEP. <aside> The spelling for a Dependent Type I recall seeing as Π[] in academic papers, I think? If you wrote it out in English it might be Pi[], so `Pi["include"]` in your example above. However Pi[] is a pretty unintuitive name to say the least... </aside> Again, perhaps it would be worth leaving the Dependent Type can-of-worms to a future PEP... -- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy

Seems to me there are some unresolved questions about what such a feature would actually mean and on what set of types it would work. I'm not a type systems expert and maybe I missed something, though. One dimension is basically, does Pick[...] mean a concrete, normal runtime type or is it an abstract type that works like a Protocol (and maybe actually is one)? And furthermore, what are the rules for using a Pick type in either a "giving" role (e.g. how does a function construct a value of the right type if its return is annotated as Pick[User, "id" | "name"]) or a "receiving" role (if a function has a param annotated with that type, what is it allowed to do with that variable?) A major constraint here is that Python classes - unlike TS's which are similar to TypedDicts - contain not only data attributes, but also methods. If you try to define a concrete type that leaves out some members, you may get a "broken" class since methods can call arbitrary code that depends on those members. e.g. for the User example, say that "id" is just a hash key defined as a property def id(self): hash((self.name, self.password, self.email)). Then it's not possible to construct a concrete type that omits eg "password" attr, since the id attribute will then error. Or if Pick always functions as a Protocol constructed on the fly from the given type's interface (that on its own would be an interesting PEP-worthy topic), how useful is that in e.g. the database example, since any attribute access allowed by the Protocol could still rely on data that needs a new query? The only version where this proposal's meaning is clear to me are if Pick always gives a Protocol and/or is restricted to special types that never include methods, like TypedDicts or NamedTuples.

Pondering Pick type semantics it's very similar to type level dictionary/map. There was a discussion in past on numpy's need for a way to handle families or related overloads for data type promotion rules. One way of encoding promotion rules is a dictionary from pair of types (np.int32, np.int64) to a value (another type) np.int32. Pick here is pretty similar with main difference being you are using field names (effectively literal string) for keys. Using your example, class User: id: int name: str password: str email: str you could also express this as, User = TypeMap("User", {Literal["id"]: int, Literal["name"]: str, Literal["password"]: str, Literal["email"]: str}) For readability you could maybe have a rule that a string key be treated as equivalent of Literal to let you write, User = TypeMap("User", {"id": int, "name": str, "password": str, "email": str}) The rule would need to be done with care though to avoid ambiguity with quoted types that use quotes for runtime issues (similar to from __future__ import annotations need). For numpy example it would look like, PromotionRules = TypeMap("PromotionRules", {(np.int32, np.int64): np.int64, (np.float32, np.float64): np.float64, ...} So main generalization is TypeMap has keys that are types or tuples of types. Using the fetch_user example with TypeMap it looks like, def fetch_user(name: str) -> Pick[User, Literal["id"] | Literal["name]]: ... with rules that first argument of Pick must be a TypeMap, the second argument must be a type or union of types or type variable with bound possible key types and each type must be available as a key in TypeMap. So, def fetch_user(name: str) -> Pick[User, Literal["phone"]]: ... would be a type error of "phone" not found as a key in User. For concrete types Pick[TypeMap, type] the meaning would be just TypeMap[type]. So as an example, Pick[User, Literal["id"]] would mean User[Literal["id"]] -> int. For unions you would take the union for each key so, Pick[User, Literal["id"] | Literal["name"]] -> User[Literal["id"]] | User[Literal["name"] -> int | str. Typevars are needed for situations like numpy data rules. A simple example would be, def add_arrays(array1: np.ndarray[DType1], array2: np.ndarray[DType2]) -> np.ndarray[Pick[PromotionRules, DType1, DType2]]: ... One difference here is because PromotionRules works on pair of types it would need two arguments. The add_arrays would be equivalent to, @overload def add_arrays(array1: np.ndarray[np.int32], array2: np.ndarray[np.int64]) -> np.ndarray[np.int64]: ... @overload def add_arrays(array1: np.ndarray[np.float32], array2: np.ndarray[np.float64]) -> np.ndarray[np.float64]: ... Semantically a type variables used with TypeMaps just loop through each of the keys in the typemap and produce one overload per key. This would make it useful for any family of overloads shared across multiple functions. If you have more then one function doing overloads in a similar manner with certain type rules then it's possible a typemap would simplify it. I recently had a function with a lot of type relationships and wrote 3 overloads documenting main rules, but gave up on other rules as it would have led to a lot more overloads (likely 10-20). With TypeMaps each relationship group can be encoded together and avoid that issue. This avoids all issues of class/protocol argument to Pick and what it means. This requires that argument to Pick is always a TypeMap which is basically just a dict[tuple[type, ...], type] with maybe rule that length of tuples be fixed for a given TypeMap. For tuple of length one case (User) I just did dict[type, type] to make it more readable.