[15:10:09] <xrogaan> jaraco: also, why did you replace IRCDict ?
[15:10:41] <jaraco> First, I found it didn't have the .pop method (so I added the pop method).
[15:11:04] <jaraco> Then, I realized it was also not a subclass of dict, so I was about to make it a subclass of dict.
[15:11:38] <jaraco> As I started doing that, I realized it duplicated a lot of functionality that I'd already implemented in a different class... a class which is more general purposed and designed to do what (I thought) IRCDict did.
[15:11:58] <jaraco> Turns out, as you pointed out, IRCDict did something slighly differently.
[15:12:27] <xrogaan> yeah, it was there to provice a dict-like with the specificity of irc :p
[15:12:46] <jaraco> So that functionality is now restored.
[15:12:58] <jaraco> In the changeset I pushed a few minutes ago.
[15:13:18] <jaraco> Along with doctests to capture the functionality.
[15:14:19] <aclark> hah i just used pandoc last night for the first time
[15:14:49] <aclark> errr, two nights ago when demo'ing pelican
[15:14:58] <aclark> there's an os x binary installer fortunately
[15:17:30] <xrogaan> aclark: jobs is dead. Where is your god now ?
[15:48:06] <jaraco> And I don't want to be responsible for implementing methods unrelated to the custom behavior.
[15:48:26] <papna> For two, the person who wrote the isinstance check is almost certainly wrong, and you wouldn't want to support it. If they WERE right, then what they deserve is an actual dict, which you aren't really providing. If they're wrong and we want to lie to them, you don't have to actually subclass dict for that these days and not doing so still improves your code's reliability.
[15:48:50] <papna> For three, your discussion of type information not based on behavior reflects a suboptimal use of Python.
[15:49:10] <jaraco> xrogaan: it didn't work fine. It was missing a pop method and it didn't have any test cases against it. True, it performed its advertised function, but when I wanted to use a Python 2.3 .pop method on it, it failed.
[15:52:30] <jaraco> xrogaan: Agreed. And there's no need of Python either. We could just write assembly, or we could all just stick with Python 1.5. It worked too. But here's the thing, irclib requires Python 2.3, so I should expect that a dict instance will have a pop method.
[15:53:17] <xrogaan> it was a hack to respect the irc rfc
[15:53:24] <xrogaan> and the use of IRCDict is limited
[15:57:32] <jaraco> papna: if they're calling isinstance, what they're testing for is "is this object's class a subclass of dict". If they want to restrict to only strict dict instances, they should use "instance.__class__ is dict". One of the primary tenants of OO programming is that you can subclass an object and instances of that subclass _are_ also instances of the parent class.
[15:58:09] <jaraco> To say that that's suboptimal Python is to say that an OO approach to Python is suboptimal.
[15:58:35] <jaraco> In the past, subclassing built-in types has been problemmatic, but with new style classes, that has been dramatically improved, and subclassing built-in types is an effective way to implement functionality.
[15:58:41] <jaraco> I use it all the time with great success and joy.
[15:59:22] <papna> Subclassing types that aren't intended to be subclassed leads to buggy code.
[15:59:31] <papna> dict's only API for subclassing is to provide __missing__
[15:59:51] <papna> Subclassing dict otherwise leads to problematic code that must rely on implementation details.
[16:00:38] <jaraco> papna: do you have a reference for that? The docs for Python 2.2 suggest otherwise: http://www.python.org/download/releases/2.2/descrintro/#subclassing
[16:00:40] <papna> It also does not provide any benefit when writing idiomatic Python code, which empatically does not use type information semantically.
[16:01:06] <xrogaan> hey, you can't do bold + emphasis with rest ?
[16:01:08] <papna> jaraco: that shows how class-type unification allows types in C to work like normal Python classes.
[16:06:04] <xrogaan> markdown is simple: _**strong**: blah_
[16:06:38] <xrogaan> Well, rest can't do that. Plus, it is not a very easy to read
[16:07:00] <papna> You asked 10 seconds ago if ReST could do that and don't know if there's a minor workaround.
[16:07:18] <papna> Even if there isn't, you can define a directive to display in whatever style you want.
[16:07:41] <papna> And it sounds appropriate if the thing is a warning style you want to use over and over.
[16:08:21] <xrogaan> I don't _want_ to define anything. I'm using it to write text and not wast my time hacking around and upgrading things by buckets.
[16:08:22] <papna> ReST might suck and Markdown might be better, but basing this on a fairly small issue that you ostensibly haven't even deeply researched to know if you're missing something? seems a bit hasty.
[16:09:18] <papna> If you're manually typing the same thing out over and over to be a "warning", you're using it wrong anyhow. It might be that's not what you want, but THAT would be a criticism that might be on the scale of comparing it to Markdown.
[16:10:05] <xrogaan> i'm converting my wordpress blog to pelican
[16:10:19] <xrogaan> I couldn't make pelican works with markdown, so i use rest
[16:10:33] <xrogaan> and it was pandoc that generated the rest files
[16:11:59] <xrogaan> papna: so, is there a workaround ?
[16:13:39] <papna> xrogaan: You can make a Warning directive or whatever
[16:13:47] <papna> xrogaan: Or just provide a role
[16:13:58] <papna> give it a name like .. role:: bolditalics
[16:14:06] <papna> Then define bolditalics in the CSSD