On 27/11/2007, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 27, 2007 at 02:02:02PM +0100, Markus Gritsch wrote:
> > How about applying the attached patch?
>
> --- mysqlconnection_orig.py     2007-09-27 02:18:28.000000000 +0200
> +++ mysqlconnection.py  2007-11-27 13:57:30.324125000 +0100
> @@ -110,10 +110,7 @@
>                  # For MySQLdb 1.2.1 and later, we go
>                  # encoding->unicode->charset (in the mysql db)
>                  if self.need_unicode and not isinstance(query, unicode):
> -                    try:
> -                        query = unicode(query, self.encoding)
> -                    except UnicodeError:
> -                        pass
> +                    query = unicode(query, self.encoding)
>                  return cursor.execute(query)
>              except MySQLdb.OperationalError, e:
>                  if e.args[0] in (MySQLdb.constants.CR.SERVER_GONE_ERROR, 
> MySQLdb.constants.CR.SERVER_LOST):
>
>    I remember people had been persuading me to add that try/except for years,
> and now you are starting the reverse process! :)

I have been persuading you to add the "and not isinstance(query,
unicode)" part of the if for month and since it was added, the MySQL
backend gracefully accepts Unicode in queries ;)

However, this silently swallowing of an UnicodeError was introduced
from 0.9.1 -> 0.9.2 and I don't see what bug this solves.  It just
makes me feel uneasy.  If there is really a case for which the
conversion to unicode using self.encoding raises UnicodeError, then
fixing it by swallowing this exception is definitely not the correct
solution to the problem.

Unless someone can come up with a short code example of a program
which works only with the try/except being there and fails without it,
I would rather like to see the try/except being removed.

Markus

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Reply via email to