Thank you! That makes me feel quite a bit better.
On Thursday, 6 May 2021 at 11:59:14 UTC-4 Mike Bayer wrote:
> the caching routine for datatypes is matching up the names of the
> parameters to the internal state of the object. any name will reproduce
> as long as you name the parameters and
the caching routine for datatypes is matching up the names of the parameters to
the internal state of the object. any name will reproduce as long as you name
the parameters and internal attributes the same.
On Thu, May 6, 2021, at 11:52 AM, Steven James wrote:
> I originally came to that concl
I originally came to that conclusion, and I agree that replacing it with a
tuple does fix it, but I still can't explain why using a different
parameter name also fixes it.
On Thursday, 6 May 2021 at 11:46:53 UTC-4 Mike Bayer wrote:
> this is a regression in SQLAlchemy in that the TypeDecorator
this is a regression in SQLAlchemy in that the TypeDecorator is being applied
to caching without giving the end user any clue or API to control this process.
the name "choices" is not significant, it's that the parameter as given is
trying to be part of a cache key, so turn this into a tuple for
This one is baffling me. The following example throws an exception about an
unhashable type, related (I think) to the new query caching in 1.4.
However, if I change the parameter name to AltType.__init__ to ANYTHING
other than `choices`, it works fine. I can't find any reference to the name
`ch
