#python - Sun 25 Mar 2007 between 00:00 and 00:10

polpakTFKyle: except you cannot do that
TFKylepolpak: sure you can, with ABC's
ironfroggyyes thats fine, but that has little or nothing to do with type checking, actually.
polpakTFKyle: x = Foo(); del x.mymethod; somefunction_that_uses_mymethod(x);
TFKyledefine the functionality in an ABC then make all classes implement subclass from it
polpak: user error then
haysironfroggy: right now im struggling with something where I think I have to use isinstance, or violate encapsulation
TFKylepolpak: if anyone did that you should kick them
ironfroggyhays: explain why then
polpakTFKyle: read the section labeld "Type checking to find bugs" please
TFKylepolpak: sure, sec
haysironfroggy: http://rafb.net/p/fTjn1L86.html
polpakTFKyle: why should I have to inherit from your class just to use your function when the whole interface isn't required, and my class needs/wants to do something different
TFKylepolpak: sure there is, for easy checking
polpak: and I'm not doing 1000line base-classes, I'm talking maybe 20-line ABC's
haysironfroggy: that code puts parentheses around stuff to enforce evaluation order, but it doesn't need to. but they are there to ensure when defaults need to be overridden, it generates a correct statement
ironfroggyhays: where do you think you want to use isinstance?
polpakTFKyle: it doesn't matter. It's a needless restriction
TFKyle: if my code breaks, it's my problem not yours
TFKylepolpak: not sure if it's covered in that paper, but subclassing is useful for documentation and stuff (inheriting docstrings is nice)
haysironfroggy: probably in __mul__ and __add__, so I can see what I am multiplying/adding
to flatten the parse tree essentially
ironfroggythe most useful interfaces dont have common docstrings. i can subscript nearly any container, but no docstring would be good for all of them.
hays: to make sure that its only added to or multiplied with objects of the same type?
polpakTFKyle: the only thing your function should care about is "does this thing support the methods I'm going to use on it" and even there, 99% of the time you'd just raise an exception anyway which the interpreter will already do. No need to throw the extra if code in there
TFKyleironfroggy: dunno, __hash__ could have a shared docstring for example, of course the implementation varies on the class implementing it if you put that info in the docstrings it wouldn't work that well
polpakTFKyle: if for example you have a function which you pass files to and I suddenly want to pass a StringIO, your function fails cause you're checking to make sure it derives from file. Or if I define my own special object that supports all the file like methods but does something completely different.. why can't I use that object with your code also?
TFKyle: you're confusing the argument. There's nothing wrong with subclassing. The bad behavior comes in _requiring_ people to subclass to use your function/method/objects/etc.
TFKylepolpak: what about collision, where say you expect classes that have say .exports and .imports for attributes, another project also defines a similar type, but it's for something completely different (say one being a shipping app, the other being some sort of file format)
pembo13how can i get the final url/location that urllib2 has gone to after a redirect?
TFKylepolpak: personally I think that should be specified explicitly that StringIO is an I/O stream, none of this implicit .read/.write stuff that is currently there
haysironfroggy: no, lets say __mul__ in ConditionAnd is called with a ConditionAnd and ConditionAnd. it should return a single ConditionAND with 4 leaves. But if it gets a ConditionAND and a ConditionOR, it should return a ConditionAND with a ConditionAND node and a ConitionOR Node.
TFKylepolpak: isinstance is a nice way to see if something provides a specific interface (and someone said explicitly that it does)
haysI think this requires typechecking to implement, without doing something like checking Condition.statement
actionTFKyle doesn't like it too much when implicitly rules
TFKyledoesn't like it too much when implicitly rules
polpakTFKyle: the only semi decent solution to that (if it even happens all that often which I doubt) is zope.interfaces. But even there you (as the function author expecting to get something that can imports or exports) SHOULD NOT CARE if me passing a bad object will break my code
ithkuilTwisted currently supports two methods of integrating wxPython. Unfortunately, neither method will work on all wxPython platforms (such as GTK2 or Windows). It seems that the only portable way to integrate with wxPython is to run it in a separate thread.
TFKylepolpak: what's wrong with ABC's?
apart from that some people might need to rework their code, meh

Page: 2 9 16 23 30 37 44 51 58 65