#Type Lens

1 messages · Page 1 of 1 (latest)

gentle vortex
#

This thread serves as a discussion point for anything related to the type-lens library.

placid cedar
#

huh, but that thing doesn't exist

lone mountain
errant zinc
#

april 2!? I was looking for this days ago!

#

do y'all have existing usage of type-lens generally? I looked up ParameterView in the org and didn't see anything

junior crow
# errant zinc do y'all have existing usage of type-lens generally? I looked up ParameterView i...

No, here's the history.

In Litestar, we had a thing called ParsedType which was basically what TypeView is now, notwithstanding recent changes.

At some point, ParsedType was changed into into a thing called FieldDefinition and a bunch of other things were added to it, like implicit parsing of openapi metadata, a coupling to litestar's KwargDefinition and DependencyKwarg types, and a name field.. so where ParsedType was intended to be an interface over type introspection, it got overloaded with this other stuff.

type-lens's TypeView, was seeded with the implementation of ParsedType from the commit immediately before all of the above was added to it.

ParameterView was Litestar's representation of a signature parameter, which was removed from Litestar at the same time as these other changes were made to ParsedType.

The intention with type-lens is to first build an object that properly represents a type and allows useful introspection of that type, and then some abstractions over that to represent places where a type is used, such as a signature parameter or a model field.

Unwinding the litestar FieldDefinition implementation will take some time, but it needs to be done. Particularly the openapi metadata parsing stuff really doesn't belong there, but unfortunately it has been exposed as public api so ripping it out isn't an option.

Any more questions on this front, I'll be happy to answer as best as I can.

junior crow
errant zinc
#

I haven't gotten that far, maybe the TypeView doesnt get constructed and it's a None or Empty instead.

In attempting to actually use ParameterView on an unknown function, it seems like you'd have to (roughly)

hints = get_type_hints()
signature = inspect.signature(fn)
params = [ParameterView.from_parameter(p, hints) for p in signature.parameters]

but then you hand it

def foo(bar):
    return bar

and it immediately fails because of that check. (which you could try/exception, but it's except all the time, and in my mind, you'd ultimately still want a ParameterView instance handy for the common interface to decide what to do with the parameter

#

I'm trying to write something like a FunctionView that would actually perform the get_type_hints call and handle the various issues with raw get_type_hints().

junior crow
maiden sand
#

Is it possible to add a "type lens ELI5" example in the docs? I will be honest, the readme does not tell me what I can do "at runtime"

junior crow
#

yeah, we'll get there 🙂

maiden sand
#

the way we show a hello world route in litestar

#

maybe meta typing users can understand, but I dont 🙃

junior crow
#

this type of library would mostly be used by other library authors, I'd expect. No so much targeting end-user applications

maiden sand
#

yes I assumed as much, at least having a hello world would tell me "this is not the library you are looking for"

junior crow
# 
def foo(bar):
    return bar

I'd be pretty happy if we just treated this as

def foo(bar: Any) -> Any: ...
#

we could get there by looking at the difference b/w inspect.Signature and get_type_hints and assign Any to param/return type that exists in former, and not latter

#

I know I just renamed it to is_subtype_of but now I really want to call it is_consistent_with 🙈

junior crow
errant zinc
#

i had just assumed calling it on a type was using __init___ and the return type would be the thing itself

delicate quailBOT
errant zinc
#

Based even on code inside type-view, i think it perhaps makes sense to for there to be a TypeView attribute that does this:

TypeView(int).<this> == int
TypeView(list[int]).<this> == list
TypeView(SomeArbitraryGeneric).<this> == SomeArbitraryGeneric
TypeView(SomeArbitraryGeneric[Foo]).<this> == SomeArbitraryGeneric

I.e. self.origin or self.annotation essentially.

seems like get_instantiable_origin and get_safe_generic_origin could disappear because they'd be so simple they could be inlined.

I also have at least a couple of places where I have this same pattern used to get at the bare annotated type rather than a specific generic variant

errant zinc
#

tl;dr interest in convenience property for this? and what would you call it, if so?

junior crow
#

interested, sure

#

sorry I have been super busy for the last couple of weeks (and will be so for a little while yet)

#

the idea behind get_safe_generic_origin is to support rebuilding a type on 3.8 that was originally a generic collection e.g., List[<something>] -> List[<something else>] - where get_origin(List[<something>]) would be list and then list[<something_else>] would fail b/c of 3.8.

#

I'd consider any part of this api up for change/debate though!

errant zinc
#

do you have a candidate name for my suggested property? to me "origin" would have been the name, and i feel like typing's get_origin is either poorly named or has bad semantics.

and in case it wasnt clear, i meant get_safe_generic_origin could disappear, because the impl to @property def safe_generic_origin would be return _SAFE_GENERIC_ORIGIN_MAP[self.<this property>]

#
  1. Interest in exposing Empty and EmptyType top level? I had my own equivalent sentinels, but i'd rather just not.
  2. i'm not sure where to go with the whole discussion on is_subtype_of. I'd be happy to just add a simpler is_subclass_of as mentioned in the later comments, if it's worth having both (which i def think it is if we specifically dont want subtype_of to handle arbitrary input types ahead of time). I think my personal needs will be sufficed by that
errant zinc
#

submitted prs for all the things except #3 so far

errant zinc
delicate quailBOT
errant zinc
#

I dont suppose you're back yet? 😇

#

i just ran into another net-new feature that it'd be really convenient to be able to depend upon TypeView for in a released version of cappa 😛

maiden sand
errant zinc
delicate quailBOT
#
DanCardin
<:pull_open:882464248721182842> [litestar-org/type-lens] feat: Enable unsupported runtime typing syntax in 3.8/3.9.

Description

E.g.

from __future__ import annotations
class Foo:
    bar: list[int] | None = None

This doesn't break anything in 3.8/3.9 due to the future import...until you use something like CallableView or TypeView to perform runtime type analysis, at which point it fails.

This PR makes use of eval-type-backport to make this function correctly in 3.8/3.9.

Created ·
errant zinc
#

after this, i'll need to rebase my cappa branch, but i'm reasonably certain it's got everything I need for it to be depended on.

So if I can get passing tests there, i'd love to stage a release

errant zinc
#

@spice oar https://github.com/litestar-org/type-lens/pull/33. I believe this is the last of the bits and bobs I need personally, currently. and since peter hasn't been around...

I'd "just merge" most of the changes, except there was previously a reluctance for my change to the is_subtype_of method, that i hopefully justify in my comment.

delicate quailBOT
spice oar
#

Your explanation makes sense to me, seems good to merge

errant zinc
#

awesome. i'm probably going to stage a release afterward then. thanks!

delicate quailBOT
maiden sand
errant zinc
#

oh right!

#

lol, just forgot to update my remotes since i got the commit bit!

errant zinc
errant zinc
maiden sand
errant zinc
#

yea, from experience it needs someone that's a maintainer on the pypi package itself

errant zinc
#

which means @lilac raptor or @gentle vortex 😬 (thanks for making that info public pypi!)

gentle vortex
#

I’ll check in just a bit

maiden sand
gentle vortex
#

sorry in meetings first thing until 11

errant zinc
#

np no rush

lilac raptor
#

taking a look now to see if i have this privs

errant zinc
#

published, lovely! thanks!

gentle vortex
#

whatd u change?

lilac raptor
#

It was still registered to be published under the jolt org

gentle vortex
#

RIP

errant zinc
delicate quailBOT
errant zinc
#

I wish all of typing wasn't built in. Its very annoying to deal with across versions

errant zinc
errant zinc