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. 'nuff said, Raymond Hettinger
Sounds like a good idea. --Guido van Rossum (home page: http://www.python.org/~guido/)
Raymond Hettinger wrote:
Date: Tue, 25 Nov 2003 07:26:15 +0100
I would like to nominate input() also. It is often misused by beginners. A better choice is almost always raw_input(). In the standard library, fpformat.py seems to be the only one using it. Further, I see Demo/classes/Dbm.py uses it, but that seems to be all. How about banishing input() too? yours, Gerrit. -- 59. If any man, without the knowledge of the owner of a garden, fell a tree in a garden he shall pay half a mina in money. -- 1780 BC, Hammurabi, Code of Law -- Asperger's Syndrome - a personal approach: http://people.nl.linux.org/~gerrit/english/
I won't name names, but input() has a very important friend who happens to be a dictator, the author of the tutorial, and the creator of a well thought out programming language. The risks are clearly documented. So no one can't say they weren't warned. Also, it does have its uses and is friendly to beginning programmers who don't enjoy having to coerce strings back to the data type they actually wanted. Also, it is somewhat nice to be able enter expressions in personal, interactive scripts. all-builtins-have-at-least-one-friend, Raymond Hettinger
I would like to nominate input() also. It is often misused by beginners.
I've seen many programming texts for real beginners that use it -- it's handy to be able to read numbers before you have explained strings or how to parse them. So I say let's be kind on input(). --Guido van Rossum (home page: http://www.python.org/~guido/)
[Gerrit]
I would like to nominate input() also. It is often misused by beginners.
[Guido van Rossum]
So I say let's be kind on input().
Fine with me :) But... at [0], raw_input() and input() are mentioned as minor regrets, as functions which should actually not have been builtins. Have you now changed your mind, or did I misinterpret [0], or is it something else? [0] http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf yours, Gerrit. -- 134. If any one be captured in war and there is not sustenance in his house, if then his wife go to another house this woman shall be held blameless. -- 1780 BC, Hammurabi, Code of Law -- Asperger's Syndrome - a personal approach: http://people.nl.linux.org/~gerrit/english/
Note that the regrets were minor. :-) The problem is that these are almost never used in real programs; real programs use sys.stdin.readline() so they can properly handle EOF. But their main use, teaching Python to beginners without having to expose the whole language first, requires either that they are built in or that the teacher sets up a special environment for their students. For the latter, a PYTHONSTARTUP variable pointing to a file with teachers' additions does nicely, but requires a level of control over the student's environment that's not always realistic. (Especially not when the student is teaching herself. :-) Perhaps a special module of teacher's helpers could be devised, and a special Python invocation to include that automatically? --Guido van Rossum (home page: http://www.python.org/~guido/)
Barry Scott wrote:
It's a hard-to-read repr(), actually. Guido once published a list of Python regrets, which can be found at: http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf At page 5, it suggests to drop `...` for repr(...), so unless Guido changed his mind (I don't think so), this is a deprecation-canddate as well: as is callable() and input(), by the way. yours, Gerrit. -- 147. If she have not borne him children, then her mistress may sell her for money. -- 1780 BC, Hammurabi, Code of Law -- Asperger's Syndrome - a personal approach: http://people.nl.linux.org/~gerrit/english/
Yes, backticks will be gone in 3.0. But I expect there's no hope of getting rid of them earlier -- they've been used too much. I suspect that even putting in a deprecation warning would be too much. (Maybe a silent deprecation could work.) So maybe these could be added to the list of language features moved to a "doomed" section.
Note: I tried to find it in the language reference and its not in the index but then neither is %.
I think none of the operators are in the index of the reference manual. I don't know how to resolve this; indexing non-alphanumeric characters may not be easy in LaTeX, I don't know. --Guido van Rossum (home page: http://www.python.org/~guido/)
Sounds like a good idea. --Guido van Rossum (home page: http://www.python.org/~guido/)
Raymond Hettinger wrote:
Date: Tue, 25 Nov 2003 07:26:15 +0100
I would like to nominate input() also. It is often misused by beginners. A better choice is almost always raw_input(). In the standard library, fpformat.py seems to be the only one using it. Further, I see Demo/classes/Dbm.py uses it, but that seems to be all. How about banishing input() too? yours, Gerrit. -- 59. If any man, without the knowledge of the owner of a garden, fell a tree in a garden he shall pay half a mina in money. -- 1780 BC, Hammurabi, Code of Law -- Asperger's Syndrome - a personal approach: http://people.nl.linux.org/~gerrit/english/
I won't name names, but input() has a very important friend who happens to be a dictator, the author of the tutorial, and the creator of a well thought out programming language. The risks are clearly documented. So no one can't say they weren't warned. Also, it does have its uses and is friendly to beginning programmers who don't enjoy having to coerce strings back to the data type they actually wanted. Also, it is somewhat nice to be able enter expressions in personal, interactive scripts. all-builtins-have-at-least-one-friend, Raymond Hettinger
I would like to nominate input() also. It is often misused by beginners.
I've seen many programming texts for real beginners that use it -- it's handy to be able to read numbers before you have explained strings or how to parse them. So I say let's be kind on input(). --Guido van Rossum (home page: http://www.python.org/~guido/)
[Gerrit]
I would like to nominate input() also. It is often misused by beginners.
[Guido van Rossum]
So I say let's be kind on input().
Fine with me :) But... at [0], raw_input() and input() are mentioned as minor regrets, as functions which should actually not have been builtins. Have you now changed your mind, or did I misinterpret [0], or is it something else? [0] http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf yours, Gerrit. -- 134. If any one be captured in war and there is not sustenance in his house, if then his wife go to another house this woman shall be held blameless. -- 1780 BC, Hammurabi, Code of Law -- Asperger's Syndrome - a personal approach: http://people.nl.linux.org/~gerrit/english/
Note that the regrets were minor. :-) The problem is that these are almost never used in real programs; real programs use sys.stdin.readline() so they can properly handle EOF. But their main use, teaching Python to beginners without having to expose the whole language first, requires either that they are built in or that the teacher sets up a special environment for their students. For the latter, a PYTHONSTARTUP variable pointing to a file with teachers' additions does nicely, but requires a level of control over the student's environment that's not always realistic. (Especially not when the student is teaching herself. :-) Perhaps a special module of teacher's helpers could be devised, and a special Python invocation to include that automatically? --Guido van Rossum (home page: http://www.python.org/~guido/)
Barry Scott wrote:
It's a hard-to-read repr(), actually. Guido once published a list of Python regrets, which can be found at: http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf At page 5, it suggests to drop `...` for repr(...), so unless Guido changed his mind (I don't think so), this is a deprecation-canddate as well: as is callable() and input(), by the way. yours, Gerrit. -- 147. If she have not borne him children, then her mistress may sell her for money. -- 1780 BC, Hammurabi, Code of Law -- Asperger's Syndrome - a personal approach: http://people.nl.linux.org/~gerrit/english/
Yes, backticks will be gone in 3.0. But I expect there's no hope of getting rid of them earlier -- they've been used too much. I suspect that even putting in a deprecation warning would be too much. (Maybe a silent deprecation could work.) So maybe these could be added to the list of language features moved to a "doomed" section.
Note: I tried to find it in the language reference and its not in the index but then neither is %.
I think none of the operators are in the index of the reference manual. I don't know how to resolve this; indexing non-alphanumeric characters may not be easy in LaTeX, I don't know. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (6)
-
Barry Scott -
Gerrit Holl -
Guido van Rossum -
Jeremy Fincher -
Raymond Hettinger -
Raymond Hettinger