Since there are no stubs for sqlalchemy by default, the decorator will be seen as Any value by mypy. One option would be to not complain about redefinitions if the first definition is known to have an Any type.
More generally, hybrid_property could be an alias for property, and in that case the errors are more clearly false positives.
Guido suggested in #220 that someone could try to build hybrid property support on top of mypy's descriptor support. I was able to get this going by defining a typed_hybrid_property generic class (in a pyi file), parameterized by python type and sql type. I had to define my hybrid properties as separate functions with different names (like _prop_get, _prop_expr and such), and then merge them all into the name I wanted using prop = hybrid_property(_prop_get, expr=_prop_expr).
I have so far been unable to convince mypy to type-check the multipart definition (using @prop.setter) because that relies on the magic in mypy's semantic analyzer which notices @Property declarations.
It would be super-nice if mypy provided a way to "get the @Property behavior" for additional decorators not named in the mypy source.
@lincolnq This is something that probably can be done by a plugin. We currently have a plugin hook for classes decorated with a given decorator. We can probably just add a similar hook for functions.
@ckarnell I don't think it is possible with the current plugin API. This would require either #7468 or #6760 (depending on how exactly we implement these).
I was running into the same problem with two hybrid fields.
I was able to fix the error: Name 'XXX' already defined by adding # type: ignore and interestingly also fix the other issue by just reordering the functions.
error: Name 'name' already defined on line XXX
error: Name 'aliases' already defined on line XXX
error: overloaded function has no attribute "default"
error: overloaded function has no attribute "__iter__" (not iterable)
Another solution that I found and that doesn't require using #type: ignore is to make the hybrid_property have the same typing as a normal property when type checking.
fromsqlalchemyimportBase, Column, StringifTYPE_CHECKING:
# This makes hybrid_property's have the same typing as normal property until stubs are improved.hybrid_property=propertyelse:
fromsqlalchemy.ext.hybridimporthybrid_propertyclassFirstNameOnly(Base):
first_name=Column(String)
@hybrid_propertydefname(self):
returnself.first_name@name.setterdefname(self, value):
self.first_name=value
Reacted by Stephen J. Fuhry, Henrik Christensen, TornaxO7, Thomas Jost, Jon Bringhurst, Zach B, Trevor Gross, Johnny Villegas, Ľubomír Brindza, senseysensor and 1 more
It seems that sqlalchemy is deprecating their mypy plugin. Unfortunately, that means it is unlikely for this issue to be solvable in a neat way. That being said, another plugin could eventual implement either #7468 or #6760, to fix this.
That being said, I don't think this issue is actionable beyond the above plugin issues, so I am going to close it.
Activity
gvanrossum commented on Jan 5, 2018
Can you include the content of test.py?
Deimos commented on Jan 5, 2018
Oh sorry, it's just exactly the same as that example code (only the first class def):
from sqlalchemy import Base, Column, String from sqlalchemy.ext.hybrid import hybrid_property class FirstNameOnly(Base): first_name = Column(String) @hybrid_property def name(self): return self.first_name @name.setter def name(self, value): self.first_name = valueI had the wrong line numbers on the error above (edited now), the error is on line 11, @name.setter.
gvanrossum commented on Jan 5, 2018
I guess this is because mypy doesn't understand that @hybrid_property because similar to @property.
Also possibly you may have to take this up with https://github.com/JelleZijlstra/sqlalchemy-stubs.
JukkaL commented on Jan 5, 2018
Since there are no stubs for sqlalchemy by default, the decorator will be seen as Any value by mypy. One option would be to not complain about redefinitions if the first definition is known to have an Any type.
More generally, hybrid_property could be an alias for property, and in that case the errors are more clearly false positives.
lincolnq commented on Sep 4, 2018
Guido suggested in #220 that someone could try to build hybrid property support on top of mypy's descriptor support. I was able to get this going by defining a typed_hybrid_property generic class (in a pyi file), parameterized by python type and sql type. I had to define my hybrid properties as separate functions with different names (like _prop_get, _prop_expr and such), and then merge them all into the name I wanted using prop = hybrid_property(_prop_get, expr=_prop_expr).
I have so far been unable to convince mypy to type-check the multipart definition (using @prop.setter) because that relies on the magic in mypy's semantic analyzer which notices @Property declarations.
It would be super-nice if mypy provided a way to "get the @Property behavior" for additional decorators not named in the mypy source.
ilevkivskyi commented on Sep 4, 2018
@lincolnq This is something that probably can be done by a plugin. We currently have a plugin hook for classes decorated with a given decorator. We can probably just add a similar hook for functions.
Btw, we are currently working on SQLAlchemy stubs (and soon mypy plugins) at https://github.com/dropbox/sqlalchemy-stubs
ckarnell commented on Sep 11, 2019
@ilevkivskyi Do you have an idea of how a plugin could be used to silence these errors mentioned above if you use a .setter or .expression?:
It sounds like the support for @property is baked into mypy itself, so I'm not sure how we would use a plugin to avoid these errors.
ilevkivskyi commented on Sep 12, 2019
@ckarnell I don't think it is possible with the current plugin API. This would require either #7468 or #6760 (depending on how exactly we implement these).
marc-mabe commented on Nov 21, 2019
I was running into the same problem with two hybrid fields.
I was able to fix the error: Name 'XXX' already defined by adding # type: ignore and interestingly also fix the other issue by just reordering the functions.
Original:
Error;
Modified to:
Result:
Ignore spurious redefinition errors
ennnas commented on Feb 18, 2021
Another solution that I found and that doesn't require using #type: ignore is to make the hybrid_property have the same typing as a normal property when type checking.
reference
TornaxO7 commented on Aug 11, 2021
@ennnas I'm getting
error: Name "TYPE_CHECKING" is not definedback. How do you get this variable?
hauntsaninja commented on Aug 11, 2021
from typing import TYPE_CHECKING
TornaxO7 commented on Aug 11, 2021
Thank you! :)
emmatyping commented on Dec 27, 2024
It seems that sqlalchemy is deprecating their mypy plugin. Unfortunately, that means it is unlikely for this issue to be solvable in a neat way. That being said, another plugin could eventual implement either #7468 or #6760, to fix this.
That being said, I don't think this issue is actionable beyond the above plugin issues, so I am going to close it.