> After re-reading previous posts on the subject, I had an idea. Let's > isolate these functions in the documentation into a separate section > following the rest of the builtins. > > The cost of having these builtins is not that they take up a few entries > in the directory listing. Also, it's no real burden to leave them in > the code base. The real cost is that when learning the language, after > reading the tutorial, the next step is to make sure you know what all > the builtins do before moving on to study the library offerings. > > The problem with buffer() and intern() is not that they are totally > useless. The problem is that it that it is darned difficult an everyday > user to invent productive use cases. Here on python-dev, one defender > arose for each and said that they once had a use for them. So, let's > leave the functionality intact and just move it off the list of things > you need to know. In both cases, it would have saved me some hours > spent trying to figure out what they were good for - I wish someone had > just said, "you can ignore these two". These functions are just > distractors in a person's mental concept space. > > There's really nothing wrong with have apply() and coerce() being > supported for old code. The problem with them is why bother even > knowing that they exist - they just don't figure into modern python > code. Any time spent learning them now is time that could have been > spent learning about the copy or pickle modules or some such. > > Moving these functions to a separate section sends a clear message to > trainers and book writers that it is okay to skip these topics. Getting > them out of the critical path for learning python will make the language > even easier to master. > > Some are highly resistant to deprecation because it makes their lives > more difficult. However, I think even they would like a list of "things > you just don't need to know anymore". In other words, you don't have to > wait for Py3.0 for a clean house, just push all the clutter in a corner > and walk around it. Sounds like a good idea. --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