4 ms·
It's an interesting point, both the argument it makes and the background. I'm one of the people who was unkeen to move to Py3. My reason was mostly the numerou
by rich_sasha 2y ago
It's an interesting point, both the argument it makes and the background.
I'm one of the people who was unkeen to move to Py3. My reason was mostly the numerous and totally unnecessary minor syntax changes (print -> function, map and filter becoming lazy, str/unicode etc) with no major benefits in the upgrade for my use case (data science), other than compatibility. Some of the new syntax was neither bad or good (what's so wrong with print being a statement? Add a printfn function if you really want one), some were IMHO outright bad (map and filter becoming lazy, reduce being kicked out to a module), str->unicode was maybe the only good one, but even that is controversial. The deliberate neutering of `bytes` was unnecessary too. Python 3 brought various implementation improvements and nice new syntax, which could have been implemented in a Python 2 syntax too (dict and set comprehensions for example)
So I saw no reason why Python 3 couldn't in fact be syntactically compatible with 2, and saw the whole thing as a bit of an upgrade circus: wanna keep using the language? Make these arbitrary changes because someone thought print ought to be a function.
You could argue it was the same disregard for stability as the now many versions of Python 3.
- robertlagrant 2y agoWhy print as a function? From the PEP[0]: print is the only application-level functionality that has a statement dedicated to it. Within Python’s world, syntax is generally used as a last resort, when something can’t be done without help from the compiler. Print doesn’t qualify for such an exception. At some point in application development one quite often feels the need to replace print output by something more sophisticated, like logging calls or calls into some other I/O library. With a print() function, this is a straightforward string replacement, today it is a mess adding all those parentheses and possibly converting >>stream style syntax. Having special syntax for print puts up a much larger barrier for evolution, e.g. a hypothetical new printf() function is not too far fetched when it will coexist with a print() function. There’s no easy way to convert print statements into another call if one needs a different separator, not spaces, or none at all. Also, there’s no easy way at all to conveniently print objects with some other separator than a space. If print() is a function, it would be much easier to replace it within one module (just def print(*args):...) or even throughout a program (e.g. by putting a different function in __builtin__.print). As it is, one can do this by writing a class with a write() method and assigning that to sys.stdout – that’s not bad, but definitely a much larger conceptual leap, and it works at a different level than print. [0] https://peps.python.org/pep-3105 https://peps.python.org/pep-3105
- rich_sasha 2y agoYes, if Python was made from scratch, then perhaps function is better (I don't really mind). But breaking one of the most commonly used statements for what is essentially aesthetics? No thanks. Introduce a function that does the same if you like. That's precisely my point, this syntax change (and many others) was entirely unnecessary, put people off upgrading, then got them told off for being dinosauric luddites. Frankly, it's not even that consistent. Is `del dict[key]` necessary when you can call `dict.pop`? Either way, these would be fine discussions to have, but not when you consider the people upgrading thei codebases.
- robertlagrant 2y ago> Is `del dict[key]` necessary when you can call `dict.pop`? Reason for Python 4 detected!
- skeledrew 2y agoCan't override/hack `print` as a statement, which is something I've found myself doing often enough to be happy that it's a function.