Hover on property with setter during assignment shows nothing #5218

Activity

1. github-actions

   added

   language-serverIssues specific to our IDE integration rather than type checkingIssues specific to our IDE integration rather than type checking

   on Oct 13, 2026
2. StefanBRas commented on Oct 13, 2026

   

   StefanBRas

   on Oct 13, 2026

   Author

   More actions

   For reference ty shows the just assigned type, which I (and the submitter of this issue) finds incorrect
3. Aayushyaash commented on Oct 14, 2026

   

   Aayushyaash

   on Oct 14, 2026

   Contributor

   More actions

   Hi @StefanBRas,

   I was hoping to help solve this issue, so I dug into the codebase to see how this is currently handled.

   I noticed there's actually a test in write_target_type.rs with a comment explaining why it behaves this way right now:

   "Writing through a property, a descriptor or __setattr__ runs a setter, which produces no type Pyrefly can attribute to the target, so the target reports nothing. In particular the getter is never consulted: reading p.p and d.d gives int, which must not leak into the store."

   So returning None was an intentional decision at the time to make sure getter types wouldn't leak into write targets (and to avoid what tools like Pyright and ty do, where they attach the RHS value type to the attribute).

   That said, showing nothing isn't a solution.

   I was thinking about what we could do here. Whenever someone hovers over an attribute in an assignment, if it resolves to a property with a setter, we could look up the setter method and display its parameter type.

   Here is how both symmetric and asymmetric property would look before and after:

   # Example 1: Symmetric Property
   class A:
       def __init__(self) -> None:
           self._x: int | None = None
   
       @property
       def x(self) -> int | None:
           return self._x
   
       @x.setter
       def x(self, value: int | None) -> None:
           self._x = value
   
   a = A()
   # Before: Hover on `x` returns None ("no information available")
   # After:  Hover on `x` returns `(attribute) x: int | None`
   a.x = 1
   
   
   # Example 2: Asymmetric Property
   class B:
       @property
       def items(self) -> tuple[int, ...]:
           return self._items
   
       @items.setter
       def items(self, value: Iterable[int]) -> None:
           self._items = tuple(value)
   
   b = B()
   # Before: Hover on `items` returns None
   # After:  Hover on `items` returns `(attribute) x: Iterable[int]` (the setter's input contract)
   b.items = [1, 2]

   This way, we provide useful hover information on assignments while ensuring we never leak the getter type or show the RHS literal.

   Do you think this makes sense, or did you have a different behavior in mind? If this sounds good to you and the maintainers, I'd love to claim the issue and work on a PR.
4. StefanBRas commented on Oct 15, 2026

   

   StefanBRas

   on Oct 15, 2026

   Author

   More actions

   I think for me as a user, what would help the most would be to show that this is a property where the setter and getter differs in type. Even when they don't differ I think it's nice to know that it has a custom setter, because it can be surprising that assigning to a variable actually runs a function.

   From a quick read of the LSP spec on HoverRequest there's no restrictions on what you're allowed to show so I don't think there's anything blocking from showing the full information
5. rchen152

   added the

   Bug

   issue type on Nov 5, 2026
6. rchen152 commented on Nov 5, 2026

   

   rchen152

   on Nov 5, 2026

   Contributor

   More actions

   Maybe we could use the getter type when the property is symmetric and print the property's getter and setter when it's asymmetric.

   👍React with 👍2Reacted by Stefan and Aayush Yash
7. Aayushyaash commented on Nov 6, 2026

   

   Aayushyaash

   on Nov 6, 2026

   Contributor

   More actions

   Showing both getter and setter types for asymmetric properties makes a lot of sense.

   Here’s a quick before & after of what this would look like for reads vs writes:

   ---

   1. Symmetric property (getter == setter)

   class A:
       def __init__(self) -> None:
           self._x: int | None = None
   
       @property
       def x(self) -> int | None:
           return self._x
   
       @x.setter
       def x(self, value: int | None) -> None:
           self._x = value
   
   a = A()
   val = a.x   # Read
   a.x = 1     # Write

   • Read (val = a.x): (property) x: int | None (unchanged)
   • Write (a.x = 1):
     • Before: None
     • After: (property) x: int | None

   ---

   2. Asymmetric property (getter != setter)

   from collections.abc import Iterable
   
   class B:
       def __init__(self) -> None:
           self._items: tuple[int, ...] = ()
   
       @property
       def items(self) -> tuple[int, ...]:
           return self._items
   
       @items.setter
       def items(self, value: Iterable[int]) -> None:
           self._items = tuple(value)
   
   b = B()
   res = b.items     # Read
   b.items = [1, 2]  # Write

   • Read (res = b.items): (property) items: tuple[int, ...] (unchanged)
   • Write (b.items = [1, 2]):

     • Before: None

     • After:

       (property) items: Iterable[int]
       
       Property Accessors:
         Setter: Iterable[int] (assigned here)
         Getter: tuple[int, ...]
       

   The hover displays the setter's type first since that's what the assignment accepts, with the getter listed below for context.

   ---

   Custom Descriptors (__get__ / __set__)

   In write_target_type.rs (test_property_and_descriptor_target) and attr.rs, AttrSetter::DescriptorSetter is handled alongside PropertySetter and currently has the same None target behavior.

   Since Pyrefly already has get_descriptor_setter_value() for extracting the __set__ value parameter, I can extend the implementation to cover custom descriptors in the same PR.
8. Aayushyaash commented on Nov 6, 2026

   

   Aayushyaash

   on Nov 6, 2026

   Contributor

   More actions

   I'll start working on this and open a PR. #claim

   ❤️React with ❤️1Reacted by Rebecca Chen
9. github-actions

   assigned

   Aayushyaash

   on Nov 6, 2026
10. github-actions commented on Nov 6, 2026

    

    github-actionsBot

    on Nov 6, 2026 – with GitHub Actions

    More actions

    @Aayushyaash you've claimed this issue — it's now assigned to you. Thanks for picking it up! 🎉
11. github-actions

    added

    has-open-pr

    on Nov 8, 2026