| 00:51.53 | *** join/#storm jml (n=jml@ppp121-44-217-216.lns1.hba1.internode.on.net) |
| 01:48.12 | *** join/#storm Fujitsu (n=fujitsu@ubuntu/member/fujitsu) |
| 02:21.39 | *** join/#storm bigdog (n=scmikes@49-66-14-216-arpa.cust.cinci.current.net) |
| 03:37.53 | *** join/#storm bigdo1 (n=scmikes@49-66-14-216-arpa.cust.cinci.current.net) |
| 04:19.47 | *** join/#storm jml (n=jml@ppp108-61.static.internode.on.net) |
| 04:43.45 | *** join/#storm jkakar (n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca) |
| 06:13.14 | *** join/#storm jml_ (n=jml@ppp108-61.static.internode.on.net) |
| 07:48.52 | *** join/#storm rafael (n=rafael@moinmoin/fan/rafael) |
| 07:50.33 | *** join/#storm mcella (n=michele@ip-132-247.sn2.eutelia.it) |
| 07:56.57 | *** join/#storm jkakar (n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca) |
| 09:21.43 | *** join/#storm jkakar (n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca) |
| 10:59.15 | *** join/#storm rafael (n=rafael@moinmoin/fan/rafael) |
| 12:02.55 | *** join/#storm niemeyer (n=niemeyer@200-138-46-51.ctame705.dsl.brasiltelecom.net.br) |
| 12:05.32 | niemeyer | Good morning! |
| 12:08.54 | statik | morning |
| 13:14.41 | *** join/#storm bigdog (n=scmikes@49-66-14-216-arpa.cust.cinci.current.net) |
| 13:17.02 | niemeyer | statik: Your pybots branch is in.. |
| 13:17.17 | statik | niemeyer: thanks! I'll kick off a test run now |
| 13:17.27 | niemeyer | statik: I belive it fixes the issues you found regarding the __bases__ error |
| 13:55.39 | statik | niemeyer: storm is green now http://www.python.org/dev/buildbot/community/trunk/ (it runs on the amd64 ubuntu gutsy builder) |
| 13:58.14 | niemeyer | statik: Very nice! |
| 14:00.42 | niemeyer | statik: Is it testing the the postgres and mysql backends as well? |
| 14:01.15 | statik | niemeyer: yes, all three. currently all three are lumped in the same test run, as there is no easy way to invoke them separately (the sqlite tests are always run) |
| 14:01.42 | niemeyer | statik: Right.. I was just wondering if the environment variables were correctly set |
| 14:02.23 | statik | niemeyer: I think they are, is the log not showing the mysql and pg tests being run? |
| 14:02.56 | niemeyer | statik: It shows, but that's not necessary true |
| 14:03.15 | niemeyer | statik: If the environment variables are not set, tests will be skipped instead |
| 14:03.36 | niemeyer | Ran 318 tests in 38.542s |
| 14:03.39 | statik | niemeyer: ah, your testrunner reports skips as passes, rather than skips? |
| 14:03.45 | niemeyer | Hmm.. they're not being skipped I belive |
| 14:03.49 | niemeyer | Right |
| 14:04.16 | statik | tsk tsk |
| 14:04.18 | statik | :) |
| 14:04.19 | niemeyer | statik: Well.. it may depend on the runner |
| 14:04.21 | niemeyer | :-) |
| 14:05.08 | statik | niemeyer: yes, I've been frustrated by this in the unittest runner. nose recently added a nice way to skip tests, I've been using that on the review-board tests (django project), and I really like getting a report of which tests passed, which ones were skipped, and which ones failed |
| 14:05.47 | statik | you just raise a SkipTest (don't remember the exact name) exception in your test |
| 14:06.05 | niemeyer | That's cool indeed |
| 14:06.54 | *** join/#storm mcella (n=michele@ip-132-247.sn2.eutelia.it) |
| 14:24.46 | *** join/#storm jukart (n=jukart@bas12-toronto12-1177554452.dsl.bell.ca) |
| 14:27.28 | *** join/#storm jukart_ (n=jukart@lsfw01.lovelysystems.com) |
| 14:53.42 | radix | niemeyer: so do you actually think referencesets should support __contains__? |
| 14:54.05 | radix | niemeyer: after thinking for a bit about how we generally don't override magic methods for storm objects, I'm even thinking that supporting slice notation was perhaps a bad idea |
| 14:54.11 | niemeyer | radix: Yes, it sounds reasonable at first sight |
| 14:54.38 | niemeyer | radix: Hmm.. I think we're overriding them when possible |
| 14:54.55 | niemeyer | radix: We don't do it with __len__ specifically because of the side effects in a few cases |
| 14:54.59 | radix | hm |
| 14:55.18 | niemeyer | radix: But we have __iter__, __eq__, etc |
| 14:55.31 | radix | ResultSet has __eq__? |
| 14:55.50 | niemeyer | radix: Nope.. I can't think of a reasonable way to implement that |
| 14:56.02 | radix | ok.. what did you mean by __eq__? the Variables? |
| 14:56.14 | radix | I was specifically only referring to ResultSet, sorry, should have mentioned that |
| 14:56.26 | niemeyer | radix: In ReferenceSet and in comparable expressions |
| 14:56.33 | niemeyer | radix: Ah, ok |
| 14:56.39 | radix | oh, hm, ReferenceSet |
| 14:57.23 | *** join/#storm oubiwann (n=oubiwann@c-75-71-99-53.hsd1.co.comcast.net) |
| 14:57.43 | radix | ReferenceSet doesn't have __eq__, but Reference does |
| 14:57.58 | niemeyer | radix: I think in this specific case we can do it somewhat nicely by issuing a single query |
| 14:58.06 | niemeyer | radix: True |
| 14:58.09 | radix | niemeyer: yeah, I think the operation we have in mind for the implementation of __contains__ makes sense |
| 14:58.22 | radix | i.e. the efficient query |
| 14:58.28 | radix | I just wonder if it should be given that interface |
| 14:58.53 | niemeyer | radix: Right.. and it's boring to build such query by hand for many-to-many reference sets |
| 14:59.01 | niemeyer | oubiwann: Morning! |
| 14:59.11 | oubiwann | niemeyer: hello! |
| 14:59.32 | oubiwann | niemeyer: how goes it? |
| 14:59.49 | niemeyer | oubiwann: Pretty good! Happy to be working on non-secret projects ;-) |
| 14:59.57 | radix | niemeyer: so, what about something like result_or_reference_set.contains(o)? |
| 14:59.58 | oubiwann | hehehe |
| 15:00.05 | oubiwann | hear-hear to that one! |
| 15:00.33 | radix | it just looks like these python-magic-methods in ResultSet are out of place compared to the rest of the API |
| 15:00.52 | niemeyer | radix: I'm fine with it as well.. but to be honest I don't see the advantage when compared to "o in result_or_reference" |
| 15:00.53 | radix | and I'm worried about people confusing the magic methods for something that's perhaps less expensive than it is |
| 15:01.13 | niemeyer | radix: Oh, hmmm |
| 15:01.21 | radix | or, in some framework, where people receive a resultset and think it's a list |
| 15:01.51 | radix | it's interesting to note that apparently we explicitly decided against __getitem__ support for non-slices |
| 15:02.20 | niemeyer | radix: result_set[index] works, IIRC |
| 15:02.51 | radix | oh, I misread the code |
| 15:03.08 | radix | never mind that point :) |
| 15:03.57 | niemeyer | radix: I'm on the fence about that one.. on one side I agree that it's good to tell that the operation isn't a local one |
| 15:04.45 | niemeyer | radix: on the other hand, all operations on the result set and on reference sets are lazy, and will cause queries to be made |
| 15:05.43 | niemeyer | radix: So we're being consistent so far, and having "a in result_or_ref" querying the database shouldn't come as a surprise |
| 15:06.30 | radix | I lost you there |
| 15:06.48 | radix | I don't understand how a thing can be "lazy, and will cause queries to be made" |
| 15:07.29 | niemeyer | radix: Lazy in the sense that we don't have a list of objects which represent the reference set, such as sqlalchemy does (or did) |
| 15:08.00 | niemeyer | radix: Objects will be retrieved from the database when the reference set is iterated.. |
| 15:08.14 | radix | or when you do an "in" operation |
| 15:08.29 | niemeyer | radix: Right, or when .remove() is called, or etc.. |
| 15:08.41 | radix | and if I see some arbitrary piece of code that does an "in" operation between two unknown objects, I don't expect it to be doing something remote, generally |
| 15:08.54 | radix | but if I see ".contains", I go "I don't know what .contains means", and look up the documentation :) |
| 15:12.41 | niemeyer | radix: Cool.. I'm copying that discussion to the bug.. we can move on with contains() and see how it goes. |
| 15:25.30 | *** join/#storm rafael (n=rafael@moinmoin/fan/rafael) |
| 15:36.54 | *** join/#storm johan (n=jdahlin@200-171-140-32.dsl.telesp.net.br) |
| 15:44.09 | *** join/#storm oubiwann (n=oubiwann@c-75-71-99-53.hsd1.co.comcast.net) |
| 17:32.46 | *** join/#storm jamesh (n=james@canonical/launchpad/jamesh) |
| 17:44.30 | niemeyer | radix: Regarding _parse_set and _parse_get, they are underscored because they're "protected", not "private".. IOW, they're supposed to be overwritten by subclasses, but are not part of the public API |
| 18:22.12 | statik | what does the [f=nnnn] mean in storm commit messages on merges? |
| 18:22.57 | statik | also, newbie question, does storm support prepared statements? I heard that SQLObject does not, but dbapi does |
| 18:25.28 | niemeyer | statik: It points to the bug fixed. |
| 18:25.53 | statik | niemeyer: I should have guessed, that is a good idea |
| 18:25.54 | niemeyer | statik: Hmmm.. No, Storm doesn't support them.. |
| 18:26.03 | niemeyer | statik: I actually wonder if DBAPI does |
| 18:26.42 | *** join/#storm rafael (n=rafael@moinmoin/fan/rafael) |
| 18:27.31 | statik | niemeyer: this talks about dbapi support for parameter substitution. I think mysql uses '?' as the placeholder also http://docs.python.org/lib/module-sqlite3.html |
| 18:27.50 | niemeyer | statik: Yes, but that's not about prepared statements I guess |
| 18:28.15 | niemeyer | statik: I don't think the DBAPI has a standard way to prepare statements |
| 18:28.21 | statik | niemeyer: you're right, I mix those together when I should not |
| 18:28.52 | niemeyer | statik: IIRC, some modules will cache prepared statements automatically |
| 18:35.48 | statik | niemeyer: I see. found this also http://mail.python.org/pipermail/db-sig/1999-July/000977.html |
| 18:40.07 | *** join/#storm jamesh (n=james@canonical/launchpad/jamesh) |
| 18:53.20 | *** join/#storm hansi_p (n=hans@88.116.224.102) |
| 19:45.59 | *** part/#storm hansi_p (n=hans@88.116.224.102) |
| 20:06.28 | *** join/#storm dinho (n=dinho@201.79.78.20) |
| 20:36.02 | *** join/#storm jukart (n=jukart@bas12-toronto12-1096805369.dsl.bell.ca) |
| 20:37.48 | *** join/#storm jukart_ (n=jukart@lsfw01.lovelysystems.com) |
| 21:38.23 | *** part/#storm johan (n=jdahlin@200-171-140-32.dsl.telesp.net.br) |
| 22:42.22 | *** join/#storm oubiwann (n=oubiwann@c-75-71-99-53.hsd1.co.comcast.net) |
| 23:04.13 | *** join/#storm mcella (n=michele@ip-132-247.sn2.eutelia.it) |
| 23:12.43 | tjs | morning all :) |
| 23:30.35 | *** join/#storm jbellis (n=jbellis@69.60.124.247) |
| 23:40.38 | *** join/#storm dinho (n=dinho@201.79.98.42) |
| 23:44.20 | *** join/#storm jml (n=jml@ppp121-44-217-216.lns1.hba1.internode.on.net) |