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].
Here was I thinking "oh well, topic mentions PHP, how long before people start popping up with obligatory completely irrelevant "PHP sucks" posts?" And here you are.
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.
I think that your idea is correct. I would rephrase it to say, "... explain why the PHP function does not belong in the language specification or the standard library to begin with..."
Except the problem most people actually want to solve is not "convert newlines to <br>", it is "convert some text to html", and this function may lead to think that it does that, when it only does a tiny fraction of that. And that's how injections are born.
I've never once had the impression that nl2br did anything more than make whitespace significant in an HTML document. Even during my first days of using PHP... I don't think there's anything in the documentation or even trivially basic experimentation that could reasonably lead someone to believe that.
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 does less than making HTML whitespace-significant. It's unsuitable for use on HTML markup, because newlines in <script>, inside tags, attributes, comments, etc. should not be changed.
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.
What is being suggested is that the plaintext may contain a random html tag (Perhaps if supplied by a user, or perhaps because that tag is meant to be displayed as plaintext as well. The reason doesn't rally matter, "tags" in any situation are still valid plaintext). By passing text to something that replaces new lines with br the implication is that it is now safe to drop into HTML -- however now that tag from before can take effect (particularly bad if its a script tag). Thus, this function doesn't make sense unless it is at least also coupled with HTML escaping.
It's implied because basically the only context under which <br>'s are used is when appearing in HTML. If someone is taking text, converting the newlines to <br>'s, then there's a 99.9% chance that the next step is that that text is going to be placed in a larger HTML document. Unless of course I'm forgetting some alternative use of <br>'s.
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 have never, ever seen nl2br referred to as making anything secure or safe. It just converts new lines to <br />s. That's what the manual says it does. That's what tutorials say it does. That's what the function name very obviously shows.
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.
>I have never, ever seen nl2br referred to as making anything secure or safe.
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.
It should be better documented to not directly print user input in HTML context, and there should be a very obvious best-practices[1] guide for newbies explaining what to do (and what not to do). But nl2br could only be dangerous is you misunderstand the function's name, description, sample code, and everything else on the documentation.
> By passing text to something that replaces new lines with br the implication is that it is now safe to drop into HTML
> 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.
Have you actually read the PHP documentation page for nl2br? People are absolutely using it that way and not making any remark about safety or security. As an anecdote, when I started using PHP, I began to use nl2br to change the newlines in my HTML to <br> tags and output them. You can mark that up to me being a bad developer I guess but I literally got the idea from the PHP manual.
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.
It's named quite well and explains exactly what it does. If you think this converts text to html you haven't read the manual. RTFM before programming or get out of the fucking field.
Why not? Most languages have a standard library that does all kinds of simple but useful stuff. PHP is aimed at the web so a function that deals with part of the web/non-web mismatch seems like a useful thing to include.
Removing it would simply cause newbies to have to wrange with str_replace to build trivial web apps.
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).
4.0.5 was released in 2001, more than a decade ago. When complaining about a language, complain about a current, feature breakage, not an old one that has since been fixed (5.3.0 came out in 2009, 3 years ago).
So, where's a problem? That is some godforsaken version that is dead for many years and nobody uses it it was working differently? It's not a problem, it's a feature - the language evolves and changes according to what people need. It happens with all languages and all libraries and all code.
4.0.5 was more than 11 years ago. 5.0 was released 8.5 years ago. Why, let's discuss something that happened 11 years ago as if it is relevant to anything now.
Actually it can be quite a useful function. In your __unsubstantiated__ opinion it's dumb.
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.
What's wrong with not enforcing privacy? I have not seen privacy be abused writ large in Python programs, except in cases that are very practical (mostly finicky forms of testing that hit a few critical code paths).
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.
Nothing wrong with it. Like nothing wrong with having nl2br function. Some don't need private class members. Some don't need nl2br. The wrong is when people think whoever doesn't need exactly what they need is dumb.
True, but why bake it into the language if it's not enforced? Most OOP requires encapsulation which requires private members and the ability to enforce this privacy. It should not be up to the user to enforce it, as that will never happen.
What's wrong with it? It's a bug by design that allows a useless feature (access to private members ... why not make everything public then?) and allows the destruction of a key concept of OOP: encapsulation.
Which is perfectly fine if you don't need encapsulation.
It seems your question is "why is there a 'private' variable convention, for something that isn't enforced by the language?"
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.
[1] http://www.php2python.com/wiki/function.nl2br/