Why should __eq__ unconditionally return False? Shouldn't
it return True if the names and values of the fields in the
two rows are the same?
===================================
With regard to __getattr__, how would the object.attribute
syntax work in the face of situations such as this:
--------------------------------
create table a1 (
"Field, /Name/" int
)
--------------------------------
What about fields whose names are Python keywords?
--------------------------------
create table a2 (
username varchar(8),
pass varchar(30)
)
--------------------------------
Python wouldn't allow the expression "row.pass", since
"pass" is a keyword.
===================================
I won't add these features to kinterbasdb unless you can
explain how to circumvent the problems mentioned above.
However, I would consider introducing pluggable Connection,
Cursor, and Row constructors in version 3.2. These would
work much like Dynamic Type Translators, in that kinterbasdb
would use default versions unless the client programmer
provided customized versions.
I would want to allow the same sort of hierarchical
"bubbling" that applies to type translators. That is, the
client programmer could specify a custom Connection
constructor at the module level, a custom Cursor constructor
at the module or connection level, and a custom Row
constructor at the module, connection, or cursor level.
kinterbasdb would use the most specifically specified
constructor in each of those situations.
In the presence of this pluggable constructor mechanism and
a commitment on kinterbasdb's part to a stable interface for
the _RowMapping class (which would be renamed), you could
implement your the __eq__ and __getattr__ methods suggested
via simple inheritance and a couple of constructor
specification calls.
What's your reaction?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=414645
Why should __eq__ unconditionally return False? Shouldn't
it return True if the names and values of the fields in the
two rows are the same?
===================================
With regard to __getattr__, how would the object.attribute
syntax work in the face of situations such as this:
--------------------------------
create table a1 (
"Field, /Name/" int
)
--------------------------------
What about fields whose names are Python keywords?
--------------------------------
create table a2 (
username varchar(8),
pass varchar(30)
)
--------------------------------
Python wouldn't allow the expression "row.pass", since
"pass" is a keyword.
===================================
I won't add these features to kinterbasdb unless you can
explain how to circumvent the problems mentioned above.
However, I would consider introducing pluggable Connection,
Cursor, and Row constructors in version 3.2. These would
work much like Dynamic Type Translators, in that kinterbasdb
would use default versions unless the client programmer
provided customized versions.
I would want to allow the same sort of hierarchical
"bubbling" that applies to type translators. That is, the
client programmer could specify a custom Connection
constructor at the module level, a custom Cursor constructor
at the module or connection level, and a custom Row
constructor at the module, connection, or cursor level.
kinterbasdb would use the most specifically specified
constructor in each of those situations.
In the presence of this pluggable constructor mechanism and
a commitment on kinterbasdb's part to a stable interface for
the _RowMapping class (which would be renamed), you could
implement your the __eq__ and __getattr__ methods suggested
via simple inheritance and a couple of constructor
specification calls.
What's your reaction?
Logged In: YES
user_id=414645
You've had about eight months to answer my complaints about
this feature request, and haven't done so, so I assume
you're not going to.