From ali at indydevs.org Wed Feb 5 04:36:26 2014 From: ali at indydevs.org (Ali-Akber Saifee) Date: Wed, 5 Feb 2014 11:36:26 +0800 Subject: [code-quality] pylint with simplejson & json Message-ID: Hi, I'm getting mixed results from pylint when it inspects the result of simplejson.loads versus json.loads. I've documented some of my findings in the stackoverflow question at http://stackoverflow.com/questions/21545409/pylint-reports-maybe-no-member-error-for-data-loaded-via-simplejson . I'm still not very clear as to why one implementation gets past pylint's checks while the other doesn't. Also out of curiosity - what would be the correct approach for dealing with a function that returns one of many primitives? best, *./?* -------------- next part -------------- An HTML attachment was scrubbed... URL: From afayolle.ml at free.fr Thu Feb 6 06:48:09 2014 From: afayolle.ml at free.fr (Alexandre Fayolle ML) Date: Thu, 06 Feb 2014 06:48:09 +0100 Subject: [code-quality] [Python-projects] New warning about print parens not a good idea? In-Reply-To: References: Message-ID: <52F32219.4030502@free.fr> 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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From carl.crowder at gmail.com Thu Feb 6 07:24:59 2014 From: carl.crowder at gmail.com (Carl Crowder) Date: Thu, 6 Feb 2014 07:24:59 +0100 Subject: [code-quality] [Python-projects] New warning about print parens not a good idea? In-Reply-To: <52F32219.4030502@free.fr> References: <52F32219.4030502@free.fr> Message-ID: <553A474D-B37D-40B6-8913-24CEC11FB4DE@gmail.com> 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 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 at 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 at python.org > https://mail.python.org/mailman/listinfo/code-quality -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.thenault at logilab.fr Thu Feb 6 10:07:28 2014 From: sylvain.thenault at logilab.fr (Sylvain =?utf-8?B?VGjDqW5hdWx0?=) Date: Thu, 6 Feb 2014 10:07:28 +0100 Subject: [code-quality] [Python-projects] New warning about print parens not a good idea? In-Reply-To: <553A474D-B37D-40B6-8913-24CEC11FB4DE@gmail.com> References: <52F32219.4030502@free.fr> <553A474D-B37D-40B6-8913-24CEC11FB4DE@gmail.com> Message-ID: <20140206090728.GA9460@logilab.fr> 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 From theller at ctypes.org Thu Feb 6 19:51:09 2014 From: theller at ctypes.org (Thomas Heller) Date: Thu, 06 Feb 2014 19:51:09 +0100 Subject: [code-quality] Bad coding style? Message-ID: <52F3D99D.7090000@ctypes.org> I sometimes have code like this: class Foo: def spam(self): .... from somewhere import method from somewhere import CONSTANT def blah(self): .... where CONSTANT defines a class attribute, anbd method is a method that I would like to call like any other methor (self.spam(), or self.blah()). This works nicely and is a compact coding style, however frosted complains about unused imports. Should I fix my coding habits, or should frosted by fixed? Thanks, Thomas From s at sashahart.net Fri Feb 7 20:15:12 2014 From: s at sashahart.net (Sasha Hart) Date: Fri, 7 Feb 2014 13:15:12 -0600 Subject: [code-quality] [Python-projects] New warning about print parens not a good idea? In-Reply-To: <553A474D-B37D-40B6-8913-24CEC11FB4DE@gmail.com> References: <52F32219.4030502@free.fr> <553A474D-B37D-40B6-8913-24CEC11FB4DE@gmail.com> Message-ID: 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 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 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 at 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 at python.org > https://mail.python.org/mailman/listinfo/code-quality > > > > _______________________________________________ > code-quality mailing list > code-quality at python.org > https://mail.python.org/mailman/listinfo/code-quality > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc at rintsch.de Fri Feb 7 22:07:15 2014 From: marc at rintsch.de (Marc 'BlackJack' Rintsch) Date: Fri, 07 Feb 2014 22:07:15 +0100 Subject: [code-quality] [Python-projects] New warning about print parens not a good idea? In-Reply-To: References: <52F32219.4030502@free.fr> <553A474D-B37D-40B6-8913-24CEC11FB4DE@gmail.com> Message-ID: <52F54B03.7050602@rintsch.de> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: From ned at nedbatchelder.com Fri Feb 7 22:38:16 2014 From: ned at nedbatchelder.com (Ned Batchelder) Date: Fri, 07 Feb 2014 16:38:16 -0500 Subject: [code-quality] Bad coding style? In-Reply-To: <52F3D99D.7090000@ctypes.org> References: <52F3D99D.7090000@ctypes.org> Message-ID: <52F55248.5020005@nedbatchelder.com> On 2/6/14 1:51 PM, Thomas Heller wrote: > I sometimes have code like this: > > class Foo: > > def spam(self): > .... > > from somewhere import method > from somewhere import CONSTANT > > def blah(self): > .... > > where CONSTANT defines a class attribute, anbd method > is a method that I would like to call like any other > methor (self.spam(), or self.blah()). > > This works nicely and is a compact coding style, however > frosted complains about unused imports. > > Should I fix my coding habits, or should frosted by fixed? This is a very unusual coding style, one that many people would object to. But more importantly, how could frosted be fixed to know that these are used? --Ned. > > Thanks, > Thomas > > > > > _______________________________________________ > code-quality mailing list > code-quality at python.org > https://mail.python.org/mailman/listinfo/code-quality From mark at semmle.com Sat Feb 8 14:05:04 2014 From: mark at semmle.com (Mark Shannon) Date: Sat, 08 Feb 2014 13:05:04 +0000 Subject: [code-quality] Bad coding style? In-Reply-To: <52F3D99D.7090000@ctypes.org> References: <52F3D99D.7090000@ctypes.org> Message-ID: <52F62B80.9020408@semmle.com> On 06/02/14 18:51, Thomas Heller wrote: > I sometimes have code like this: > > class Foo: > > def spam(self): > .... > > from somewhere import method > from somewhere import CONSTANT > > def blah(self): > .... > > where CONSTANT defines a class attribute, anbd method > is a method that I would like to call like any other > methor (self.spam(), or self.blah()). > > This works nicely and is a compact coding style, however > frosted complains about unused imports. frosted is wrong here as CONSTANT is used to build the locals() dictionary used to build the class Foo > > Should I fix my coding habits, or should frosted by fixed? Both ;) Don't forget "Readability counts". Cheers, Mark. From graffatcolmingov at gmail.com Sat Feb 8 15:25:32 2014 From: graffatcolmingov at gmail.com (Ian Cordasco) Date: Sat, 8 Feb 2014 08:25:32 -0600 Subject: [code-quality] Bad coding style? In-Reply-To: <52F62B80.9020408@semmle.com> References: <52F3D99D.7090000@ctypes.org> <52F62B80.9020408@semmle.com> Message-ID: On Sat, Feb 8, 2014 at 7:05 AM, Mark Shannon wrote: > On 06/02/14 18:51, Thomas Heller wrote: > >> I sometimes have code like this: >> >> class Foo: >> >> def spam(self): >> .... >> >> from somewhere import method >> from somewhere import CONSTANT >> >> def blah(self): >> .... >> >> where CONSTANT defines a class attribute, anbd method >> is a method that I would like to call like any other >> methor (self.spam(), or self.blah()). >> >> This works nicely and is a compact coding style, however >> frosted complains about unused imports. >> > frosted is wrong here as CONSTANT is used to build the locals() dictionary > used to build the class Foo > > > >> Should I fix my coding habits, or should frosted by fixed? >> > Both ;) > Don't forget "Readability counts". > I would have to agree with everything said so far but I am frankly a little surprised that no one has suggested an alternate way of writing your class. If, this is a fairly common pattern for you, instead of writing an import like that and taking advantage of how Python builds classes, you could define the method and the constant in a different class and then inherit from that. This is one place Python's multiple inheritance is actually a huge benefit. For example, in a.py class FooMixin: CONSTANT = 'foo' def method(self, *args, **kwargs): ... And in b.py from a import FooMixin class Bar(FooMixin, OtherParentClass): def spam(self): ... def biz(self): ... The important thing to note is that if `OtherParentClass` overrides methods in FooMixin and should take precedence it should be declared as a parent class after the mixin (as above). This does not rely on the user understanding how classes are created by Python. It is explicit, and it's readable. The issue, of course, occurs when you are perhaps not using the same method(s) and constant(s) each time. If you are defining it my dynamically, you should be able to do something like this: from somewhere import CONSTANT, method class Foo: CONSTANT = CONSTANT method = method def spam(self): ... It should look up the value in globals() and assign it appropriately. That's a bit less DRY, but if it's what you need, then you shouldn't hesitate to use it. -------------- next part -------------- An HTML attachment was scrubbed... URL: