| Subject | Re: [firebird-python] Change in type_conv default value |
|---|---|
| Author | Ismael L. Donis García |
| Post date | 2009-01-12T13:40:51Z |
I respond between lines
=========
¦¦ ISMAEL ¦¦
=========
¦¦ ISMAEL ¦¦
=========
----- Mensaje original -----
De: "Pavel Cisar" <pcisar@...>
Para: <firebird-python@yahoogroups.com>
Enviado: domingo, 11 de enero de 2009 10:14
Asunto: [firebird-python] Change in type_conv default
value
Hi all,
I'm considering to change the default behaviour for automatic type
conversion in KInterbasDB 3.3 release.
Current default setting kept for backward compatibility adds dependency
to third-party mx.DateTime module, or require you to call
kinterbasdb.init(200) as first thing after import. Because mx.DateTime
module is no more required for modern Python distributions (datetime
module is part of standard Python Library since version 2.4) and thus
not installed, one is forced to always call kinterbasdb.init(200) after
initial import or face the exception few moments later. Unfortunately,
when you forget to call init() and exception about missing mx.DateTime
module is thrown, there is no easy way how to fix that situation except
reloading the kinterbasdb module. I believe it's not just me, who is
tired to call init() or face the consequences, so I seriously consider
to change the default value in forthcoming 3.3 release of KInterbasDB
(it's really coming, I'm just finishing the complete documentation
overhaul using Sphinx and reStructured Text).
The consequence of this change would be that all legacy applications
that rely on Python 2.2 and/or mx.DateTime must be changed to explicitly
call kinterbasdb.init(1) (that's all). Applications that use type_conv
value 200 doesn't need to be changed at all. New applications are free
to call init() or use the new default, but you would be freed from
necessity of init() call in interactive sessions.
The most obvious choice for new default value is code 200, as this
translator configuration represents date/time values via the standard
library module datetime and fixed point values via the decimal module,
and that Unicode values *are* encoded and decoded automatically.
However, the 3.3 release also introduces new type_conv setting (value
300) that's basically the same as 200, but additionally enables
automatic Unicode conversion also for textual blobs. It's a very handy
feature, but due to bug/limitation in Firebird API, it's supported only
with Firebird 2.1 and newer.
So the question is two-fold:
1. Would you have any objections to change the default type_conv setting?
Not
2. If you're for the change, would you prefer to change it to 200 or 300?
300 to maintain Firebird future support
I'm considering to change the default behaviour for automatic type
conversion in KInterbasDB 3.3 release.
Current default setting kept for backward compatibility adds dependency
to third-party mx.DateTime module, or require you to call
kinterbasdb.init(200) as first thing after import. Because mx.DateTime
module is no more required for modern Python distributions (datetime
module is part of standard Python Library since version 2.4) and thus
not installed, one is forced to always call kinterbasdb.init(200) after
initial import or face the exception few moments later. Unfortunately,
when you forget to call init() and exception about missing mx.DateTime
module is thrown, there is no easy way how to fix that situation except
reloading the kinterbasdb module. I believe it's not just me, who is
tired to call init() or face the consequences, so I seriously consider
to change the default value in forthcoming 3.3 release of KInterbasDB
(it's really coming, I'm just finishing the complete documentation
overhaul using Sphinx and reStructured Text).
The consequence of this change would be that all legacy applications
that rely on Python 2.2 and/or mx.DateTime must be changed to explicitly
call kinterbasdb.init(1) (that's all). Applications that use type_conv
value 200 doesn't need to be changed at all. New applications are free
to call init() or use the new default, but you would be freed from
necessity of init() call in interactive sessions.
The most obvious choice for new default value is code 200, as this
translator configuration represents date/time values via the standard
library module datetime and fixed point values via the decimal module,
and that Unicode values *are* encoded and decoded automatically.
However, the 3.3 release also introduces new type_conv setting (value
300) that's basically the same as 200, but additionally enables
automatic Unicode conversion also for textual blobs. It's a very handy
feature, but due to bug/limitation in Firebird API, it's supported only
with Firebird 2.1 and newer.
So the question is two-fold:
1. Would you have any objections to change the default type_conv setting?
Not
2. If you're for the change, would you prefer to change it to 200 or 300?
300 to maintain Firebird future support
best regards
Pavel Cisar
IBPhoenix
Firebird QA & Python Driver Development
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-python/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-python/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:firebird-python-digest@yahoogroups.com
mailto:firebird-python-fullfeatured@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
firebird-python-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/