> Question: what will happen with all the return 1 or return 0 etc > in the std lib and in user code and in the inline doc > and docs? Ideally they would have to be changed into True and False, but there's no hurry -- 0 and 1 will continue to be valid as truth values too. > (I have found 167 return 1 in the std lib and 176 > return 0, > and also code like this > > if os.name == 'mac': > # The macintosh will select a listening socket for > # write if you let it. What might this mean? > def writable (self): > return not self.accepting > else: > def writable (self): > return 1 > > which unchanged will define a bool vs int > function.) A job for PyChecker! :-) > There are function in the std lib that return 1 on success, > 0 on failure. Are there function that do the contrary > like unix calls? Should these return True and False now. > Maybe not? I doubt there are any functions returning 0 for success and -1 for failure, but if there are, they should not be changed. > In distutil code I have seen at least > one function documented as returning 'true' > on success. Another reason to introduce a Boolean type. :-) > Then there are really predicate function/methods, > they should probably be changed? Yes. I hope that most of the C code goes through some easy choke point that makes it simple to change a lot of these at once (e.g. using Py_True and Py_False). > but that means that the situation for the > user will be *ideally* less muddy only when all > the code uses True/False everytime it makes sense, > and not 1/0. Yes, it will take time before everything is converted. That's why we must be careful to decide if we really want this. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4