Log file Viewer
#dcpython logs for Wednesday the 18th of January, 2012
[14:10:43] <jaraco> Thanks for the tip. I didn't read the code thoroughly, but was going by the comments. I'll restore that functionality and add a regression test and documentation to protect it.
[14:33:44] <jaraco> My guess is you don't have pandoc (haskell) installed in /Users/kreitz/.cabal/bin//pandoc
[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:32:08] <pmxbot> http://php.net/manual/en/control-structures.continue.php - PHP: continue - Manual
[15:35:59] <jaraco> It means forward compatibility (support for methods of future implementations of dict).
[15:41:49] <papna> Whether the methods are dict call each other is an implementation detail, and in practice they don't.
[15:42:24] <papna> New methods added won't help you, or if they do it will be by coincindence, and if that coincidence occurs in one version of Python it's not guarenteed to in another.
[15:43:06] <papna> You still have to re-implement everything, but you're shooting yourself in the foot by making what would have been loud bugs silent ones.
[15:45:49] <jaraco> If you're careful to write tests for the advertised API, then it doesn't matter what the implementation is.
[15:46:06] <jaraco> But if you don't subclass dict, and you pass your dict to something that tests isinstance(yourinstance, dict), it will not succeed.
[15:46:33] <jaraco> I want that call to succeed, because I don't want a duck-typed dict. I want a dict... with custom behavior.
[15:46:59] <papna> For one, dict doesn't HAVE a public API for what it does when subclassed beyond stuff like __missing__
[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: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: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:08] <papna> jaraco: that shows how class-type unification allows types in C to work like normal Python classes.
[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.