I think in some cases, it would be better to explain why the PHP function was a bad idea to begin with, rather than letting people bring it's mess over to Python. For example, Python doesn't need dumb shit like nl2br() [1].
nl2br is a useful function. People use it. If you don't need it, don't use it. How calling it names is helpful to anything? You didn't even bother to explain why "the PHP function was a bad idea to begin with" or why it's a "mess" or why Python people would never need it. But your certainly found time to call it "dumb shit". Here comes the downvote.
(Taken from https://github.com/php/php-src/blob/PHP-5.4.9/ext/standard/s... )
Seems to do what it says on the tin.
Removing it would simply cause newbies to have to wrange with str_replace to build trivial web apps.
The function never purports to do anything other than convert newlines to BR tags.
I don't see how that's implied at all. After all, the function is named nl2br, not html2text.
I agree the function does exactly what it says it will do. And if this was a private function used by something like text2html internally, then maybe it might be a fine function. However, as a public function, the argument is that it inspires bad programming practices, since again, it is almost certainly being used as a primitive form of "sanitation" or "conversion" before displaying plaintext in a larger HTML document.
I think if you could come up with an example of how this would be used NOT as an immediate precursor to dropping into HTML I could be convinced otherwise (and saying it is used after the other tags go through a sanitation process is a poor response, since it means this function must always follow the other one -- further proving its uselessness as a standalone function).
I think map() from Python should be removed. Its name implies to a new learner that it will draw a map, but it actually does nothing to that effect at all! No, it maps an array to a function. We must rename this dangerous function to call_a_function_on_every_element_of_an_array - or, even better, remove it from the language core ENTIRELY. If it was a private function used inside the runtime, maybe that would be fine, but it's a public part of the API.
There is also no mention in the manual that it is unsafe! One of the big problems with PHP is how easy it is to write dangerous code and how the standard manuals and tutorials often give little explanation to this.
[1] as if they would read it...
Also, your criticism of map() is kind of childish. It doesn't imply to a new learner that they will draw a map, nor does the documentation even hint at anything like that. In the Python documentation, they are given a clear use case and, if they are familiar with programming (or linguistics), understand that usage of the word map as a verb. Don't be obtuse about PHP's bad documentation.
> I don't see how that's implied at all. After all, the function is named nl2br, not html2text.
Absolutely every example from the documentation http://php.net/manual/en/function.nl2br.php uses it exactly in this manner: taking the output and immediately outputting it to the resultant HTML document. I've already described why this is unsafe (take any of these examples, replace the string with something like "Everyone knows 4 < 5", and it breaks the document due to the inclusion of "special" characters).
Now you feel that the correct use of this function is so obvious that it merits mocking my belief that it may be misunderstood by users (despite the comments on that very documentation page describing how they use it as a simple text to html converter). So given that it is so obvious to you, I repeat my original request: just give me an example where nl2br isn't ultimately used to transform plaintext before outputting it to HTML.
Plus the actual HTML-escaping tools (htmlspecialchars, htmlentities) do not make whitespace significant.
Though these days, you might arguably be better off with "white-space: pre-line" in CSS instead.
It's only safe and reliable as a part of nl2br(htmlspecialchars()) combo, so a function that does both could have been a better idea.
Prior to 4.0.5, it used "<br>". As of 4.0.5, they switched to "<br />". (As of 5.3.0, they did the obvious thing and added a second parameter, is_xhtml).
This isn't an isolated incident -- any minor update is liable to change how a function works or what parameters it can take. So you're better off writing it yourself (or doing it inline with a string replace or regular expression).
EDIT: You want to talk about dumb. An incomplete object model that has no concept of protected members and doesn't enforce encapsulation on "private" ones. This is worse than PHP4 and pales in comparison with PHP5's object model.
I have fairly recently written code in both Python and Ruby, and of the many qualitative differences in how these cultures and languages influence projects written in them, it has never occurred to me that 'real' privacy in Ruby vs. convention-based privacy in Python was the cause of any noticeable difference.
Which is perfectly fine if you don't need encapsulation.
The shortest answer is that it changes how people read the program and treat symbols branded with the underscore.
Empirically this has not caused rampant abuses or even unintentional mistakes of abuse of otherwise internal members, and so I think without more evidence that it's causing a problem now that this design experiment -- ill advised or otherwise -- has been tried and seems quite successful. Hence, an appeal to philosophy is not at odds with the implementation. The simple rule is "don't do that," coupled with "and it should be obvious when you are." Just as you probably shouldn't break into another class via reflection to use its symbols, as seen in Java or .NET, or use .send in Ruby, but still can. Python opted -- mostly for reasons of implementation complexity reduction -- to just do nothing at all.
I think this viewpoint changes quite a bit in a language that is amenable to being statically analyzed, though.