#1624: Behavior for Numeric.asdecimal=False is different than expected in many
dialects
-----------------------------------------+----------------------------------
Reporter: ged | Owner: zzzeek
Type: defect | Status: new
Priority: medium | Milestone: 0.6.0
Component: (none) | Severity: no triage selected yet
Resolution: | Keywords:
Status_field: needs questions answered |
-----------------------------------------+----------------------------------
Comment (by ged):
Replying to [comment:3 zzzeek]:
> Replying to [comment:2 ged]:
> > Quote from the docstring of Numeric:
> > {{{
> > :param asdecimal: default True. If False, values will be
> > returned as-is from the DB-API, and may be either
> > ``Decimal`` or ``float`` types depending on the DB-API in
> > use.
> > }}}
>
> *eyes pop*. That docstring is plainly incorrect. Even in 0.5,
PGNumeric coaxes Decimals into float when the flag is false. It should
be fixed in 0.5 and 0.6.
>
> >
> > Excerpt from the code of types.py/Numeric (which does pass through
values, as stated in the docstring):
> > {{{
> > #!python
> > def result_processor(self, dialect, coltype):
> > if self.asdecimal:
> > ...
> > else:
> > return None
> > }}}
>
> from my view the docs are wrong. So...again a documentation issue ?
Not only. There is also the "default" implementation in types.py/Numeric
(quoted above) which does pass values through if asdecimal is False.
> I don't mind much if we add `None` as a "passthrough guaranteed" mode
but I doubt its actually useful to anyone (assuming we ensure that
"passthrough" is used as often as possible in conjunction with the known
return type of the DBAPI to minimize overhead).
`None` as passthrough proposition is only useful (IMO) as the default
value, which would have forced users to choose what kind of data they
want, and make them aware of any conversion process either way since they
would actively ask for it. Since you don't want to change the default
value (which I perfectly understand), a forced passthrough is useless.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/1624#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|