"Mike Bayer" <[email protected]> writes: > On Wed, Nov 30, 2022, at 10:30 AM, Lele Gaifax wrote: >> 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.
Ok, I'll try to propose a issue/PR in the following days. >> >> 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. >> ... >> 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. > 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. Yes, it could be done that way too, but from the developer perspective, how is he going to create Range instances? Changing the constructor to require a "type" argument seems uglier than using a specific class. > > type-specific Range methods could be called off of each AbstractRange > type subclass, such as how the AbstractRange._resolve_for_literal() > method works. I will need to study that part. > > 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. Yes! bye, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. [email protected] | -- Fortunato Depero, 1929. -- 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/878rjsfddq.fsf%40metapensiero.it.
