Op 2005-12-13, Steve Holden schreef <[EMAIL PROTECTED]>: > Antoon Pardon wrote: >> Op 2005-12-13, Chris Mellon schreef <[EMAIL PROTECTED]>: > [...] >>>If you have a consistent API and you're checking for error values from >>>your GTK functions, then you already have a lot more code than using 2 >>>varaibles will cost you. 10 lines, maybe. >>> >>>The fact that you think setting two variables is "too hard" but you're >>>perfectly happy with checking for boolean types instead just testing >>>truth values I think is a real problem. >> >> >> These aren't just truth values. If I would have to go split in >> meaningfull truth values I would need at least three variables. >> >> >>>You aren't saving yourself any >>>performance. You're barely even saving yourself any typing, and you're >>>making your code (intentionally, it seems) that much more compllicated >>>and hard to understand. >> >> >> There is nothing complicated or hard to understand. >> > Nope, just a messy, hard to maintain misuse of a single variable for > multiple purposes.
No that variable has just one purpose, noting the state of the tube. > Perfectly simple, perfectly easy to understand and > rather more bug-prone that a straightforward separation of state and > other data. What you call other date is IMO just state information. >> I find it odd that each time declaration are mentioned people here >> react very rejecting and say that one of the features they love >> about python is the freedom that a name is not limited to a variable >> of one type, while when someone makes use of that freedom labeling >> such code as code smell. >> > There's a difference between using a single name to refer to values of > polymorphic types (which can therefore all be handled by the same code) > and using the same name to reference state information in one case (this > item has no connected callback) and other data (the callback is to > such-and-such an object). > >> But lets make an effort to make the code more readable. What >> about the following suggestion. I use a kind of EnumType with >> two values: NotRegistered and Registerd. And the name of the >> type is NotConnected. So I can then write >> >> if type(self.callback) is NotConnected. >> >> Would that be selfdocumenting enough for you? >> > It would be somewhat more self-documenting, but why not just use one > name to indicate the state and another, only meaningful in certain > states, to indicate the callback? Why should I do that? Checking the type of a variable is conceptually no different form testing set membership. So what I did, was just bringing two disjoint sets togther and working with a variable from that union. This is all in all a rather simple mathematical idea. And I don't see why I should put certain information into a seperate variable. It makes as much sense as working with numbers and using a seperate variable to store whether a particular number is postive, even or has some other characteristic. You don't seperate information you can easily acquire from the variable itself. So why should I seperate this information that is aquired just as easily? -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
