Guido> If this is deemed a useful feature (for open()), we can make a
Guido> rule about which built-ins you cannot override like this and
Guido> which ones you can.
I thought we were all adults...
For Py3k I think it should be sufficient to define the semantics of the
builtin functions so that if people want to override them they can, but that
overriding them in incompatible ways is likely to create some problems.
(They might have to run with a "no optimize" flag to keep the compiler from
assuming semantics, for instance.) I see no particular reason to remove the
current behavior unless there are clear instances where something important
is not going to work properly.
Modifying builtins seems to me to be akin to linking a C program with a
different version of malloc. As long as the semantics of the new functions
remain the same as the definition, everyone's happy. You can have malloc
leave a logfile behind or keep histograms of allocation sizes. If someone
links in a malloc library that only returns a pointer to a region that's
only half the requested size though, you're likely to run into problems.
Skip
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