On Apr 20, 2006, at 2:18 PM, Vasily Sulatskov wrote:
>> - may I suggest, that since this issue is decided completely within
>> the source code for types.String, that various implementations of
>> String, corresponding to different user preferences with regards to
>> Unicode treatment, be provided as mods which simply patch themselves
>> into the types package....that way, whatever type you put there gets
>> loaded in from an autoload scenario automatically.
> Wow. Great idea. I never event thought of replacing class in library I
> use at runtime. Thanks a lot
Well I also think people should tell me what they think of
that....its essentially more monkeypatching.
Well, it comes down to the usual trade-offs, right? How hard is it to accomplish w/o monkeypatching, and how likely is it to screw someone up who isn't expecting your patch in a stdlib object?
Unless I'm missing something, the answers here seem to be "not very hard" and "fairly likely." But, maybe I _am_ missing something. :)
WRT Vasily's three aspects of unicode,
> 1. engine.server_encoding - encoding used for storing data data in database,
> defaults to 'ascii', when I say 'ascii' I actually mean 'ascii' or
> some other encoding common to most of sqlalchemy users.
This should default to what the db says it is. :)
> 2. engine.client_encoding - encoding for client side strings, i.e.
> string that user feeds to sqlalchemy or gets from it. Defaults to
> 'ascii', or some other encoding common to most of
> sqlalchemy users
Unnecessary to have a separate SA setting. That's what the locale module is for; use that instead.
> 3. engine.autoload_unicode, defaults to False - parameter that tells sqlalchemy should id
> create columns of string type or unicode type when autoloading
> tables, or perhaps some other way to hint column types when
> autoloading.
If you're not happy with what you set at the engine level, you should just create an explicit class for that table instead of piling on the autoload options.
Python makes it easy
to just replace the namespace within a module, which is total heresy
in "proper OO land"....would people prefer I use a more verbose
"dependency injection" approach, such as this thing http://
aspn.activestate.com/ASPN/Cookbook/Python/Recipe/413268 ? or do we
think "dependency injection" of any kind is just wrong, creating
scattered application flow thats impossible to follow (which I dont
agree with, stack traces say it all usually) ?
My gut reaction is that the above cookbook recipe is very ugly and not at all Pythonic. But then I think the Java equivalents are ugly solutions-in-search-of-problems too. :)
--
Jonathan Ellis
http://spyced.blogspot.com
