Google Groups doesn't give me any option to directly reply to this post. We'll see how this approach works.
When this error came up, I wrote a scathing flame. And then I threw it away, mainly because it just isn't productive. Overriding the has_key() method seems like one of the least advisable choices one can make in python. If Guido has signed off on it, then I'm not one to argue. If anyone else decided to do this, without Guido's explicit permission...I'm going to squawk, moan, and do funny walks to draw attention to a decision that seems incredibly...questionable, to me. Like I said, I threw away my original flame, mainly because it wasn't hurting me. Now I seem to be running into exactly the same problem, so I have to complain as well. I've opened a "bug report", requested that this get refactored, and just followed the advice to copy google.appengine.ext.db.__init__.py to my own directory and am currently referencing it from there. As a software engineer, I *cringe* from that last part. That's google's documented API. It's written well enough that I feel fairly confident hacking around it...but there isn't much telling how well it maps to the production API (I'm guessing it's pretty close at present, but will change radically in the future...just the nature of the beast). Still, I thought I'd ping this thread to see if anyone else has an opinion. Regards, James ---------- Forwarded message ---------- From: "Daniel O'Brien (Google)" <d...@google.com> Date: Dec 1 2008, 5:17 pm Subject: AE 1.1.7 defines has_key on db.Model To: Google App Engine It's worth filing this as a feature request (or defect) in the public issue tracker, if you haven't already:http://code.google.com/p/ googleappengine/issues/list As far as I know this method has existed since 1.1.6: Some developers ran into issues involving cheetah, which assumes that anyhas_key method behaves like that of a dict which, as you've noted, the one nodb.Modeldoesn't. Daniel On Dec 1, 1:54 pm, Ken Tidwell <google...@gamecabinet.com> wrote: > Apparently, some bright spark has defined ahas_keymethod ondb.Model. > Doing so will preclude the creation of any Model derived from or > emulating dictionary classes (such as UserDict or DictMixin). > Thehas_keymethod in question does not follow the same semantics as >has_keyon dict so the choice of name is unfortunate, to say the least. > Any chance the method could be renamed to something less toxic and more > suggestive of its actual function (such as key_complete)? > ken --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
