[01:31] wgrant: afaict, the GitHostingClient is only called by the XmlRpcApi currently? [01:38] blr: Yep, you can currently only create a repository by trying to push it. [01:38] turnip makes the translatePath XML-RPC call. LP notices that it doesn't exist and creates it, calling back into turnip (while being called from turnip) to create the repository on disk before returning its path. [01:55] wgrant: am I right in thinking GitRepository.destroySelf() only needs to call turnip from the api client? [02:00] wgrant: are we preserving the model in the db, but setting a deleted flag? [02:14] blr: At the moment we'll delete the LP database row too. [02:14] blr: There's no reason to do complicated deferred deletion just yet. [02:16] (LP has a history of not actually deleting things, which causes no end of trouble. We should design for proper deletion from the start here.) [02:16] wgrant: ok, thanks === mup_ is now known as mup [02:44] wgrant: class StupidCache() [02:48] also enjoyed the lolcat interfaces. [02:50] Yup, StupidCache is the cache that remembers everything it's ever seen. [18:54] cjwatson: thanks for the comments re UTF-8 filtering, agree that it makes sense to handle it there. [18:56] cjwatson: the merge conflict was from providing a dependant branch on the MP, it doesn't exist in my local branch - how can I avoid that in the future? [19:02] cjwatson: also noted the style for decorators in LP appears to be func_name_decorator, will amend that as well. [20:37] cjwatson: wgrant: meeting today or tomorrow? (tomorrow in calendar, but we seem to have been shifting back a day recently) [21:18] blr: you know about the prerequisite branch facility in merge proposals? [21:19] Oh, wait, you are using that. So then I don't understand why that requires you to have conflicts [21:19] blr: I doubt it has much to do with the dependent branch; it probably just means you need to merge lp:turnip into your branch, resolve conflicts, and push [21:20] cjwatson: ok, that makes sense. [21:36] Morning. [21:37] cjwatson: Pre-reqs can in some circumstances confuse bzr merge into generating more conflicts, but I've only seen it rarelyt. [21:37] wgrant: Not on the underlay branch, surely? [21:39] Ah, no. [21:39] Misread that. [22:08] cjwatson: would json.dumps(foo, encoding='utf8') be better than ensure_ascii=False? [22:09] encoding="utf-8" is the default [22:09] ah so it is [22:09] Anyone encoding JSON as anything else should be shot :) [22:10] The default escaping is just so that it works conveniently over file objects open in binary mode; I would *hope* cornice can cope with unicode, just haven't checked [22:11] Hum [22:11] cjwatson: yes it appears to [22:12] encoding='utf8' isn't the default, is it? [22:12] ensure_ascii=False leaves it as a unicode. [22:12] (but cornice should know to encode that as UTF-8) [22:12] s'what https://docs.python.org/2/library/json says [22:13] probably encoding only takes effect if ensure_ascii=True [22:13] If ``ensure_ascii`` is false, all non-ASCII characters are not escaped, and [22:13] the return value may be a ``unicode`` instance. See ``dump`` for details. [22:13] If ensure_ascii is true, they're escaped. [22:13] Not encoded. [22:14] I wonder if encoding= is only useful for charsets that don't match ASCII. [22:14] I think encoding is meaningless with ensure_ascii=False, because it doesn't encode at all. [22:14] from a quick look at the code, I think it's actually used for decoding str objects you pass *in* [22:14] Ah, that might make sense. [22:15] It might also be relevant if eg. you use ensure_ascii=True and want EBCDIC output. [22:15] and if it's not 'utf-8' then it interposes a decoder [22:15] No, that still doesn't work. [22:15] so encoding='utf8' is not actually quite the same as encoding='utf-8' here, potentially ... .encode and .decode have always hurt my brain [22:15] I'd leave encoding= well alone :) [22:16] I think if you want differently-encoded output you have to set the encoding on the file object and use json.dump(ensure_ascii=False), or use json.dumps(ensure_ascii=False).encode() [22:17] tests pass with ensure_ascii=False at any rate [22:17] Yep, ensure_ascii=False is usually the write way to go for web stuff, since HTTP can handle the charset itself. [22:17] That's probably only meaningful if you've specifically added tests with non-ASCII data. [22:18] At least in Python 2 where you get the "helpful" default of unicode->str working magically until something outside ASCII appears. [22:19] so presumably I need a test with some latin1 data, or something of the sort [22:19] Right, I'd add one with ISO-8859-1 or something that's not valid UTF-8, and one with valid UTF-8. [22:20] And make sure that neither crashes, but that the former ref is silently omitted (so maybe have another valid UTF-8 ref in there as well or something) [22:21] cjwatson: with the ref collection I can silently omit refs unable to encode, but I think we'll also want a validator on get() which returns a 400 perhaps? [22:22] Are Pyramid's paths bytestrings or Unicode strings? [22:22] LP's are pretty much treated as Unicode, so the ref wouldn't make it through the traversal logic. [22:23] turnip-api should probably 404 if it fails to decode a path as UTF-8. [22:23] wgrant: they're unicode [22:24] I think I would prefer 400 ("could not be understood by the server due to malformed syntax"), but either works. [22:24] Hopefully Pyramid already handles it ... [22:25] Some frameworks do weird things, so we should probably check that. [22:25] cjwatson: a test should confirm either way [22:25] it would be nice not to need an explicit validator there. [22:26] http://docs.pylonsproject.org/projects/pyramid/en/1.5-branch/narr/views.html#handling-form-submissions-in-view-callables-unicode-and-character-set-issues has some stuff about this [22:26] But certainly we should check [22:27] Hm, that link is about form submissions rather than things like the path, though [22:27] probably still applicable [22:27] maaaaybe [22:27] heh [22:28] http://docs.pylonsproject.org/projects/pyramid/en/1.5-branch/narr/urldispatch.html "Note that values representing matched path segments will be url-unquoted and decoded from UTF-8 into Unicode within the matchdict." [22:28] Yay, so it's sane. [22:28] But I wonder what it does on failure. [22:29] yes self.request.matchdict['ref'] is unicode [22:29] Yeah, can't immediately find that in the docs [22:29] It's pretty modern and Zopey, so it's unlikely to be completely moronic. [22:29] But it's not unheardof for frameworks to return a str if things don't decode properly... [22:37] Looks like it raises URLDecodeError, and you can register an exception view for that if you want custom behaviour. Don't know what the default is. [22:38] Right, it probably does something sensible then. [22:39] cjwatson: So meeting in 24 hours? [22:39] And a bit, yeah.