[01:49] <dilys> Merge to rocketfuel@canonical.com/pyarch--devel--0.5: bugfix for _package_revision_param (patch-50)
[02:00] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: more (mostly) notification-related fixes to malone (patch-717)
[02:02] <dilys> Merge to rocketfuel@canonical.com/pyarch--devel--0.5: back-end refactoring (patch-51)
[02:03] <ddaa> lifeless: good example of correctness-preservingly turning a mess of interdependent modules into something much more sane providing a Facade.
[02:03] <lifeless> congrats
[02:05] <ddaa> the next step (after command name customization) is abstracting out the command line generation.
[02:05] <ddaa> you've been talking about it in London.
[02:05] <ddaa> baz is going to make that something nice to have.
[09:38] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Moving commands into the commands dir (patch-46)
[01:11] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: merge from thelove@canonical.com/bazaar--devo--1.0 (patch-47)
[01:28] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: create commands specific unit tests subtree (patch-48)
[02:02] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: merge in switch implementation from robert.collins@canonical.com--general/bazaar--switch--1.0 (patch-49)
[03:25] <dilys> Merge to thelove@canonical.com/hackerlab--devo--1.1: fix hackerlab for all current gc warnings (patch-1)
[03:27] <dilys> Merge to thelove@canonical.com/bazaar-debian--debian--1.0: use stricter gcc flags for building (patch-2)
[03:38] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: fix baz for all current gcc warnings (patch-50)
[06:07] !lilo:*! <Geert> Irssi is planning a redesign of its project web-pages.  If you want to have your say in what we do with them, please join us in #irssi-site.
[06:07] !lilo:*! <Geert> We will be brainstorming and want to know what you, the users and public, feel is missing from the site, and what would make our web presence better.  Join us now!
[08:18] <elmo> spiv: ?
[10:27] <kiko> elmo, yo?
[10:47] <kiko> wtf is our Label sample data
[10:47] <kiko> grrrrr
[11:28] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: job name munging for buildbot (patch-718)
[11:35] <kiko> BradB, I need your help.
[11:35] <BradB> ?
[11:35] <kiko> and don't say you're not here
[11:35] <BradB> i'm not here!
[11:35] <kiko> vive la france!
[11:35] <kiko> dude
[11:35] <kiko> I am doing something like way way evil
[11:35] <ddaa> kiko: ?
[11:36] <ddaa> we won a football match against your team again, or what? :-P
[11:36] <kiko> no, no
[11:36] <kiko>     def architecturesReleased(self, distroRelease):
[11:36] <kiko>         # XXXkiko I am a criminal
[11:36] <kiko>         return SourcePackageRelease.__dict__['architecturesReleased'] (self, distroRelease)
[11:37] <kiko> hey
[11:37] <kiko> if you help me I will try and pretend I fell for it
[11:37] <kiko> basically I created a view but I want to proxy some of the requests to another class
[11:38] <kiko> BradB, how do I create an SQLBase manually?
[11:38] <kiko> can I instantiate it supplying an id?
[11:38] <ddaa> ya know, if we tell mark about that, you be accommodated in the stables in Spain...
[11:38] <kiko> I will bring you candy if you don't
[11:38] <kiko> dilys, you be quiet
[11:38] <BradB> hm, /me ponders momentarily
[11:39] <BradB> kiko: architecturesReleased = SourcePackageRelease.architecturesReleased maybe?
[11:40] <kiko> I don't think it will run because of Python's class-enforcement
[11:40] <BradB> yeah, hm
[11:40] <ddaa> kiko; I am not sure I understand, but the only reason i can see of doing what you do would be to bypass getattr/getattribute...
[11:40] <kiko> it's practically the same as calling SourcePackageRelease.architecturesReleased(self, ...)
[11:40] <kiko> yes
[11:40] <kiko> precisely
[11:40] <kiko> because I am impersonating a SourcePackageRelease with a view
[11:41] <ddaa> Which is pointless, because iirc, getattr is not used for attributes which exist. Dunno about getattribute.
[11:42] <kiko> ddaa, I am creating a database view
[11:42] <kiko> this means my query returns objects that are views and not real sourcepackagereleases
[11:43] <kiko> now some attributes there I have, but some I don't
[11:43] <ddaa> A view in the DBMS sense or in the MVC sense?
[11:43] <kiko> DBMS sense.
[11:43] <ddaa> Uh... what is that view for?
[11:43] <spiv> ddaa: getattribute is always called (for new-style classes).
[11:44] <kiko> joining 1000 different tables conveniently
[11:44] <ddaa> spiv: I was sure you knew everything of that kind of evil black magic :-)
[11:44] <kiko> spiv is allowed to provide opinions too
[11:44] <kiko> just this once
[11:44] <spiv> ddaa: http://users.rcn.com/python/download/Descriptor.htm
[11:45] <ddaa> Thanks.
[11:45] <kiko> ah!
[11:45] <kiko> it's easy!
[11:45] <spiv> kiko: Mixin class? (shudder)
[11:46] <BradB> kiko: why not just get rid of the __dict__?
[11:46] <ddaa> Ha, yes, descriptor is the thing I need to do to make my "memoized_property" decorator for pyarch one day.
[11:46] <spiv> BradB: Because self is not an instance of SourcePackageRelease, if I'm understanding correctly.
[11:46] <kiko> no!
[11:47] <BradB> pass in a good self then
[11:47] <kiko> it's just a proxy through one of the view's attributes
[11:47] <kiko> spiv, yes, that's right.
[11:47] <kiko> BradB, that was SUCH a wisecrack :)
[11:47] <ddaa> kiko: why not just create another sqlos class for your view?
[11:47] <BradB> spr = SourcePackageRelease.get(theid), etc.
[11:47] <kiko> I COMMAND THE SYSTEM
[11:47] <kiko>     def architecturesReleased(self, distroRelease):
[11:47] <kiko>         # Proxy to a real SourcePackageRelease
[11:47] <kiko>         return self.sourcepackagerelease.architecturesReleased(distroRelease)
[11:48] <spiv> That looks much saner, yeah.
[11:48] <BradB> heh, somehow i don't think we had the context to know that could suffice, but yeah, makes sense :)
[11:48] <ddaa> kiko: yeah, that looks like a regular Proxy pattern.
[11:48] <kiko> modeling SQL views as objects is horrible
[11:48] <kiko> I want to go back to gardening
[11:49] <spiv> Modelling relations as objects is horrible ;)
[11:49] <kiko> I WANT THE ZODB
[11:49] <ddaa> ++
[11:49] <ddaa> hu, spiv++
[11:50] <ddaa> dunno about zodb... btw maybe we could have used the underlying ODBMS of postgres instead of bothering with sql....
[11:50] <spiv> ddaa: ZODB is goodness.
[11:50] <spiv> dunno about postgres's odbms :)
[11:50] <ddaa> I'm skeptical of NIH, by principle.
[11:51] <spiv> Plus the ZODB guys keep finding weakref gc bugs in Python, so they must be clever ;)
[11:51] <ddaa> i dunno about postgres odbms either. But I trust the postgres people to know what they are doing.
[11:52] <ddaa> spiv: somehow, code that keeps hitting obscure bugs in commodity software has to be a bit over the top.
[11:52] <spiv> ddaa: I trust the ZODB guys :)
[11:52] <BradB> ddaa: the guy who wrote most of the ZODB is now employed by google. he has much clue.
[11:52] <ddaa> That's a good cred, indeed.
[11:52] <kiko> and the guy currently in charge knows more about Python that god
[11:53] <kiko> (or about anything that's written in 1s and 0s I suspect)
[11:55] <ddaa> Invoking the name of our leader in vain.
[11:55] <BradB> ouch!
[11:56] <ddaa> Lying. You can obviously wait, your are waiting at the moment.
[11:56] <BradB> point of order: poo. end point of order.
[11:57] <ddaa> :-)
[11:58] <ddaa> The game, some like harsh.
[11:58] <BradB> the first time i played it, all i knew was something about how you can make up your own rules. i was a bit too liberal in applying that knowledge.
[11:59] <ddaa> muhuwhahaha
[11:59] <ddaa> making new rules is _hard_
[11:59] <BradB> plus i was having a semi-scuffle in text messages on my cell with my girl back in montreal, so i wasn't thinking.
[11:59] <ddaa> harder than guessing them
[12:00] <BradB> yeah, i made a stupid one
[12:00] <BradB> kinnison is like the jrr tolkien of mao rules