On Wed, Nov 30, 2022, at 10:30 AM, Lele Gaifax wrote:
> Hi!
>
> I have finally completed the "port" of my application from SA 1.4 to SA
> 2.0b.
>
> TL;DR I'm writing this report to ask an opinion about possible
> "improvements" to the Range class.
>
> Given that the previous state was already "clean" (that is, executing
> the test suite with SQLALCHEMY_WARN_20=1 did not raise any warning), I
> did not have big surprises (a loud applause here!).
>
> The area that required lot of changes has been the introduction of the
> new Range object: as said in previous emails this application uses
> DATERANGE in many entities, and TSRANGE in a couple of cases.
>
> The common modification has been replacing
>
> from psycopg2.extras import DateRange
>
> with
>
> from sqlalchemy.dialects.postgresql import Range
>
> and adapting the code accordingly, say from
>
> validity = DateRange(now, then, '[]')
>
> to
>
> validity = Range(now, then, bounds='[]'')
>
> most of that thru regexp search and replace and Emacs keyboard macros.
> Not a big deal.
>
> Where I had to spend more thinking has been in two differences, one
> minor/cosmetic, the other more substantial.
>
> On the former one, it would be nice if we could reduce the "distance"
> between the new Range class and what popular drivers provide:
>
> - "empty" vs "isempty": both asyncpg and psycopg have a "isempty"
> property, we could either rename the "empty" attribute or add an
> property alias
>
> - bounds inclusiveness: both drivers expose that thru
> "lower_inc"/"upper_inc" properties, while in SA we must say
> `range.bounds[0] == '['`
>
> - infinite bounds: likewise, they both provide "lower_inf"/"upper_inf"
> properties, whereas we must say `range.lower is None and not
> range.empty`
>
> As you see, these are "syntactic sugar" differences, easily implemented
> with some @properties.
great, we can add those.
>
> What is more substantial, that required slightly more impacting changes
> in a few cases, is that the SA Range does not have an exact notion of
> its "type", i.e. there is no way to determine the data type of an empty
> or infinite range.
>
> For example, my app shows the period of validity of (say) a contract,
> which storage is a daterange, either in a compact form (mm/dd/yy -
> mm/dd/yy) or as a more verbose, human friendly message ("from Sun, 10
> March 2022 to Fri, 15 March 2022"), in multiple languages, and taking
> into account "infinite" variants. This was implemented with a generic
> "strftime()" function taking either a date, a datetime, a DateRange or
> DateTimeRange as argument, and depending on the kind it used different
> gettext() messages to translate it to a string.
>
> To emit different messages for "endless" date ranges and "endless"
> datetime ranges, I had to modify the code path leading there, to bring
> over the "original" kind of the range.
>
> From a different perspective, we had to invent a way to distinguish the
> different kind of ranges also in the recent improvements to the Range
> class, to be able to determine a "discrete step" for each of them.
>
> So I wonder if it would be reasonable/doable/affordable if SA could grow
> a "family" of classes, derived from current Range, one for each data
> type, so that for example a DATARANGE column would be associated with a
> DateRange instance.
>
> What do you think?
how about we add a "type" field to Range itself? That would be an easier
change and also remove the need for applications to deal with all kinds of
different Range subclasses that mostly have identical behavior.
type-specific Range methods could be called off of each AbstractRange type
subclass, such as how the AbstractRange._resolve_for_literal() method works.
The Range object itself should also become a typing.Generic so that we could
pass around the type as Range[int] or Range[datetime], etc.
I think that will be a good change and continue to emphasize Range as an
abstract container type.
>
> ciao, lele.
> --
> nickname: Lele Gaifax | Dire che Emacs è "conveniente" è come
> real: Emanuele Gaifas | etichettare l'ossigeno come "utile"
> [email protected] | -- Rens Troost
>
> --
> SQLAlchemy -
> The Python SQL Toolkit and Object Relational Mapper
>
> http://www.sqlalchemy.org/
>
> To post example code, please provide an MCVE: Minimal, Complete, and
> Verifiable Example. See http://stackoverflow.com/help/mcve for a full
> description.
> ---
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected]
> <mailto:sqlalchemy%[email protected]>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sqlalchemy/87pmd4lat5.fsf%40metapensiero.it.
>
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable
Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/sqlalchemy/e1cfd4b8-a1bd-4394-8f8c-0bde6f9b1c7f%40app.fastmail.com.
