From: "Gordon McMillan" <gmcm@hypernet.com> > Jack Jansen wrote: > > > There's one slight problem with this: when you use functionality > > that is partially portable, i.e. a call that is available on Windows > > and Unix but not on the Mac. > > It gets worse, I think. How about the inconsistencies in POSIX > support among *nixes? How about NT being a superset of Win9x? How > about NTFS having capabilities that FAT does not? I'd guess there are > inconsistencies between Mac flavors, too. > > The Java approach (if you can't do it everywhere, you can't do it) > sucks. In some cases you could probably have the missing > functionality (in os) fail silently, but in other cases that would > be a disaster. The Python policy has always been "if it's available, there's a standard name and API for it; if it's not available, the function is not defined or will raise an exception; you can use hasattr(os, ...) or catch exceptions to cope if you can live without it." There are a few cases where unavailable calls are emulated, a few where they are made no-ops, and a few where they are made to raise an exception uncoditionally, but in most cases the function will simply not exist, so it's easy to test. --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