Re: [code-quality] [Python-projects] New warning about print parens not a good idea?
On 06/02/2014 02:13, Dan Stromberg wrote:
I noticed recently that pylint has begun warning about use of parens on print statements in Python 2.x code.
This seems reasonable on the face of it, except it deters writing code that runs on 2.x and 3.x, unmodified.
The error looks like: C: 5, 0: Unnecessary parens after 'print' keyword (superfluous-parens)
The offending line looks like: print('hello')
To Python 2.x, that is printing the result of a parenthesized expression. To Python 3.x, it is of course a print function.
I understand that doing something like: print('number:', 1) ...would be bad in a dual-codebase script, but having a single argument works, and indeed is often a good idea for portability.
Thoughts?
-- Dan Stromberg
_______________________________________________ Python-Projects mailing list Python-Projects@lists.logilab.org http://lists.logilab.org/mailman/listinfo/python-projects
There is a __future__ import to enable print_function in python 2[67]. I'm not sure if Pylint knows about it, though... cc-ing code-quality. Alexandre
I recently asked about the same thing, although there wasn't much discussion as a result. Pylint is aware of "from __future__ import print_function" and using it will suppress this warning you are seeing. However that is not available for Python 2.5, so it depends on what kind of compatibility you're aiming for, I guess. Given that the __future__ import exists, my preference is that pylint does warn, as using brackets near a print statement like that could represent a mistake and it's better to warn too much than too little. However I would also like to see a new error code for the print statement alone. Currently the 'superfluous-parens' warning covers all cases including 'if' and 'for' statements etc. A separate error code for the print statement/function would allow people to disable it independently and not remove the other useful warnings. On 06.02.2014, at 06:48, Alexandre Fayolle ML <afayolle.ml@free.fr> wrote:
On 06/02/2014 02:13, Dan Stromberg wrote:
I noticed recently that pylint has begun warning about use of parens on print statements in Python 2.x code.
This seems reasonable on the face of it, except it deters writing code that runs on 2.x and 3.x, unmodified.
The error looks like: C: 5, 0: Unnecessary parens after 'print' keyword (superfluous-parens)
The offending line looks like: print('hello')
To Python 2.x, that is printing the result of a parenthesized expression. To Python 3.x, it is of course a print function.
I understand that doing something like: print('number:', 1) ...would be bad in a dual-codebase script, but having a single argument works, and indeed is often a good idea for portability.
Thoughts?
-- Dan Stromberg
_______________________________________________ Python-Projects mailing list Python-Projects@lists.logilab.org http://lists.logilab.org/mailman/listinfo/python-projects
There is a __future__ import to enable print_function in python 2[67]. I'm not sure if Pylint knows about it, though...
cc-ing code-quality.
Alexandre
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
On 06 février 07:24, Carl Crowder wrote:
I recently asked about the same thing, although there wasn't much discussion as a result.
Pylint is aware of "from __future__ import print_function" and using it will suppress this warning you are seeing. However that is not available for Python 2.5, so it depends on what kind of compatibility you're aiming for, I guess.
Given that the __future__ import exists, my preference is that pylint does warn, as using brackets near a print statement like that could represent a mistake and it's better to warn too much than too little. However I would also like to see a new error code for the print statement alone. Currently the 'superfluous-parens' warning covers all cases including 'if' and 'for' statements etc. A separate error code for the print statement/function would allow people to disable it independently and not remove the other useful warnings.
that + not printing it if related __future__ import is detected would be great. -- Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42) Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services CubicWeb, the semantic web framework: http://www.cubicweb.org
If there are many people who actually want to enforce the non-use of print(arg) in 2.x for some specific reason, and not just because it is bad style to write if (a == b) or foobar((2)) - then I would strongly prefer for an error code to disable this check independently of the other useful warnings, as Carl Crowder suggested. As a user who does a lot of porting and also uses pylint for its strictness, I think it's important for pylint to be able to allow this common, concise, useful idiom for single-source portability back to 2.5. Making code portable across 2 and 3 is already more tedious than many people will accept, so as a supporter of both Python flavors I wouldn't want any more barriers from tools if they aren't necessary. On Thu, Feb 6, 2014 at 12:24 AM, Carl Crowder <carl.crowder@gmail.com>wrote:
I recently asked about the same thing, although there wasn't much discussion as a result.
Pylint is aware of "from __future__ import print_function" and using it will suppress this warning you are seeing. However that is not available for Python 2.5, so it depends on what kind of compatibility you're aiming for, I guess.
Given that the __future__ import exists, my preference is that pylint does warn, as using brackets near a print statement like that could represent a mistake and it's better to warn too much than too little. However I would also like to see a new error code for the print statement alone. Currently the 'superfluous-parens' warning covers all cases including 'if' and 'for' statements etc. A separate error code for the print statement/function would allow people to disable it independently and not remove the other useful warnings.
On 06.02.2014, at 06:48, Alexandre Fayolle ML <afayolle.ml@free.fr> wrote:
On 06/02/2014 02:13, Dan Stromberg wrote:
I noticed recently that pylint has begun warning about use of parens on print statements in Python 2.x code.
This seems reasonable on the face of it, except it deters writing code that runs on 2.x and 3.x, unmodified.
The error looks like: C: 5, 0: Unnecessary parens after 'print' keyword (superfluous-parens)
The offending line looks like: print('hello')
To Python 2.x, that is printing the result of a parenthesized expression. To Python 3.x, it is of course a print function.
I understand that doing something like: print('number:', 1) ...would be bad in a dual-codebase script, but having a single argument works, and indeed is often a good idea for portability.
Thoughts?
-- Dan Stromberg
_______________________________________________ Python-Projects mailing listPython-Projects@lists.logilab.orghttp://lists.logilab.org/mailman/listinfo/python-projects
There is a __future__ import to enable print_function in python 2[67]. I'm not sure if Pylint knows about it, though...
cc-ing code-quality.
Alexandre
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
On 07/02/14 20:15, Sasha Hart wrote:
If there are many people who actually want to enforce the non-use of print(arg) in 2.x for some specific reason, and not just because it is bad style to write if (a == b) or foobar((2)) - then I would strongly prefer for an error code to disable this check independently of the other useful warnings, as Carl Crowder suggested.
I think ``print(something)`` is even worse than ``if (a == b):`` because it is misleading if ``print`` is a statement. It lets people think it's okay to also write ``print(something, another_thing)`` which has a very different meaning and output depending on ``print`` being a statement or a function. Are there really that many people out there trying to write single source code for 2.5 and 3.x? That's quite some range. A separate error code would be good, because IMHO it is a different kind of ”error”. Ciao, Marc 'BlackJack' Rintsch -- “Web 2.0 is not about bringing people together or creating communities or making the world a better place. It's about making huge profits out of peer pressure.” -- scytale.de
participants (5)
-
Alexandre Fayolle ML -
Carl Crowder -
Marc 'BlackJack' Rintsch -
Sasha Hart -
Sylvain Thénault