Menu
▾
▴
matplotlib-devel
|
From: Federico A. <ari...@gm...> - 2014-03-06 13:47:27
|
Hello everybody Stupid simple question Is there a policy/tradition/convention to name unused variables inside the code? Even better, if I see '''var''', can I replace it with '''_var''' and nobody is going to complain? I use eclipse and it complains about that (I like that it warns me). I just wanted to know if I should just disable the warning when working on matplotlib. Federico -- Y yo que culpa tengo de que ellas se crean todo lo que yo les digo? -- Antonio Alducin -- |
|
From: Eric F. <ef...@ha...> - 2014-03-06 17:59:50
|
On 2014/03/06 3:47 AM, Federico Ariza wrote: > Hello everybody > > Stupid simple question > Is there a policy/tradition/convention to name unused variables inside the code? Not yet. > > Even better, if I see '''var''', can I replace it with '''_var''' and > nobody is going to complain? That might be a good convention. I don't particularly like a bare "_" because it is uninformative and visually a bit jarring. Even if a variable is unused, it is nice to have a slight hint in its name as to what it is. Eric > > I use eclipse and it complains about that (I like that it warns me). I > just wanted to know if I should just disable the warning when working > on matplotlib. > > Federico > |
|
From: Skip M. <sk...@po...> - 2014-03-06 18:38:07
|
On Thu, Mar 6, 2014 at 7:47 AM, Federico Ariza <ari...@gm...> wrote: > Stupid simple question > Is there a policy/tradition/convention to name unused variables inside the code? While Eric indicates there is no policy, for the Python parts of your code, I recommend you follow whatever the default is that pylint or one of the other lint-like checkers recommend. Pylint likes a leading underscore, but if you have a different natural preference, I recommend you post your query at cod...@py.... It's where all the cool static checker folk hang out. I haven't read PEP 8 in a long while. Does Guido express a preference there? Skip (not a cool static checker guy) |
|
From: Ryan M. <rm...@gm...> - 2014-03-06 20:39:16
|
Hi, I don't think a leading _ is the way to go, because that's a common convention for internal class variables--property variables that you don't intend to be part of any supported API. Personally, I've always just called things like this "junk" or "unused", but I know that's not as nice as having a symbolic notation. Ryan On Thu, Mar 6, 2014 at 11:38 AM, Skip Montanaro <sk...@po...> wrote: > On Thu, Mar 6, 2014 at 7:47 AM, Federico Ariza <ari...@gm...> > wrote: > > Stupid simple question > > Is there a policy/tradition/convention to name unused variables inside > the code? > > While Eric indicates there is no policy, for the Python parts of your > code, I recommend you follow whatever the default is that pylint or > one of the other lint-like checkers recommend. Pylint likes a leading > underscore, but if you have a different natural preference, I > recommend you post your query at cod...@py.... It's where > all the cool static checker folk hang out. I haven't read PEP 8 in a > long while. Does Guido express a preference there? > > Skip (not a cool static checker guy) > > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to > Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and > the > freedom to use Git, Perforce or both. Make the move to Perforce. > > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma |
|
From: Skip M. <sk...@po...> - 2014-03-06 20:47:48
|
On Thu, Mar 6, 2014 at 2:38 PM, Ryan May <rm...@gm...> wrote:
> I don't think a leading _ is the way to go, because that's a common
> convention for internal class variables--property variables that you don't
> intend to be part of any supported API.
But leading underscores like this are only used as attributes of
classes. I believe the OP was asking about unused local variables.
Something more like this:
mode, _ino, dev, nlink, uid, gid, size, _atime, _mtime, _ctime =
os.stat("/etc/hosts")
(Ignore that os.stat returns a posix.stat_result object on Unix-y systems.)
Skip
|
|
From: Federico A. <ari...@gm...> - 2014-03-06 20:52:21
|
Skip,
That's exactly what I was referring to.
I check PEP8 and there is no mention of unused variables.
On Thu, Mar 6, 2014 at 3:47 PM, Skip Montanaro <sk...@po...> wrote:
> On Thu, Mar 6, 2014 at 2:38 PM, Ryan May <rm...@gm...> wrote:
>> I don't think a leading _ is the way to go, because that's a common
>> convention for internal class variables--property variables that you don't
>> intend to be part of any supported API.
>
> But leading underscores like this are only used as attributes of
> classes. I believe the OP was asking about unused local variables.
> Something more like this:
>
> mode, _ino, dev, nlink, uid, gid, size, _atime, _mtime, _ctime =
> os.stat("/etc/hosts")
>
> (Ignore that os.stat returns a posix.stat_result object on Unix-y systems.)
>
> Skip
--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
-- Antonio Alducin --
|
|
From: Nelle V. <nel...@gm...> - 2014-03-06 20:51:53
|
On 6 March 2014 21:47, Skip Montanaro <sk...@po...> wrote:
> On Thu, Mar 6, 2014 at 2:38 PM, Ryan May <rm...@gm...> wrote:
>> I don't think a leading _ is the way to go, because that's a common
>> convention for internal class variables--property variables that you don't
>> intend to be part of any supported API.
>
> But leading underscores like this are only used as attributes of
> classes. I believe the OP was asking about unused local variables.
> Something more like this:
>
> mode, _ino, dev, nlink, uid, gid, size, _atime, _mtime, _ctime =
> os.stat("/etc/hosts")
The convention is to use a simple _.
mode, _, dev, nlink, uid, gid, size, _, _, _ = os.stat("/etc/hosts")
>
> (Ignore that os.stat returns a posix.stat_result object on Unix-y systems.)
>
> Skip
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
|
|
From: Federico A. <ari...@gm...> - 2014-03-06 20:54:15
|
Nelle
Is that written somewhere?
On Thu, Mar 6, 2014 at 3:51 PM, Nelle Varoquaux
<nel...@gm...> wrote:
> On 6 March 2014 21:47, Skip Montanaro <sk...@po...> wrote:
>> On Thu, Mar 6, 2014 at 2:38 PM, Ryan May <rm...@gm...> wrote:
>>> I don't think a leading _ is the way to go, because that's a common
>>> convention for internal class variables--property variables that you don't
>>> intend to be part of any supported API.
>>
>> But leading underscores like this are only used as attributes of
>> classes. I believe the OP was asking about unused local variables.
>> Something more like this:
>>
>> mode, _ino, dev, nlink, uid, gid, size, _atime, _mtime, _ctime =
>> os.stat("/etc/hosts")
>
> The convention is to use a simple _.
>
> mode, _, dev, nlink, uid, gid, size, _, _, _ = os.stat("/etc/hosts")
>
>>
>> (Ignore that os.stat returns a posix.stat_result object on Unix-y systems.)
>>
>> Skip
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries. Built-in WAN optimization and the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
-- Antonio Alducin --
|
|
From: Thomas C. <tca...@gm...> - 2014-03-06 21:00:59
|
I am with Eric, I find the bare `_` to be jarring and in some
fonts/color schemes can blend in too much. I advocate for `_name`.
Just because the variable isn't used now, does not mean it won't be
used later and having sensible variable names on them can't hurt.
Tom
On Thu, Mar 6, 2014 at 3:53 PM, Federico Ariza <ari...@gm...> wrote:
> Nelle
>
> Is that written somewhere?
>
> On Thu, Mar 6, 2014 at 3:51 PM, Nelle Varoquaux
> <nel...@gm...> wrote:
>> On 6 March 2014 21:47, Skip Montanaro <sk...@po...> wrote:
>>> On Thu, Mar 6, 2014 at 2:38 PM, Ryan May <rm...@gm...> wrote:
>>>> I don't think a leading _ is the way to go, because that's a common
>>>> convention for internal class variables--property variables that you don't
>>>> intend to be part of any supported API.
>>>
>>> But leading underscores like this are only used as attributes of
>>> classes. I believe the OP was asking about unused local variables.
>>> Something more like this:
>>>
>>> mode, _ino, dev, nlink, uid, gid, size, _atime, _mtime, _ctime =
>>> os.stat("/etc/hosts")
>>
>> The convention is to use a simple _.
>>
>> mode, _, dev, nlink, uid, gid, size, _, _, _ = os.stat("/etc/hosts")
>>
>>>
>>> (Ignore that os.stat returns a posix.stat_result object on Unix-y systems.)
>>>
>>> Skip
>>>
>>> ------------------------------------------------------------------------------
>>> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
>>> With Perforce, you get hassle-free workflows. Merge that actually works.
>>> Faster operations. Version large binaries. Built-in WAN optimization and the
>>> freedom to use Git, Perforce or both. Make the move to Perforce.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries. Built-in WAN optimization and the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> --
> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>
> -- Antonio Alducin --
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Thomas Caswell
tca...@gm...
|
|
From: Nelle V. <nel...@gm...> - 2014-03-06 21:01:52
|
On 6 March 2014 21:53, Federico Ariza <ari...@gm...> wrote:
> Nelle
>
> Is that written somewhere?
I think the convention originated from google's python style guide.
Pylint should warn you if you don't use this convention.
> On Thu, Mar 6, 2014 at 3:51 PM, Nelle Varoquaux
> <nel...@gm...> wrote:
>> On 6 March 2014 21:47, Skip Montanaro <sk...@po...> wrote:
>>> On Thu, Mar 6, 2014 at 2:38 PM, Ryan May <rm...@gm...> wrote:
>>>> I don't think a leading _ is the way to go, because that's a common
>>>> convention for internal class variables--property variables that you don't
>>>> intend to be part of any supported API.
>>>
>>> But leading underscores like this are only used as attributes of
>>> classes. I believe the OP was asking about unused local variables.
>>> Something more like this:
>>>
>>> mode, _ino, dev, nlink, uid, gid, size, _atime, _mtime, _ctime =
>>> os.stat("/etc/hosts")
>>
>> The convention is to use a simple _.
>>
>> mode, _, dev, nlink, uid, gid, size, _, _, _ = os.stat("/etc/hosts")
>>
>>>
>>> (Ignore that os.stat returns a posix.stat_result object on Unix-y systems.)
>>>
>>> Skip
>>>
>>> ------------------------------------------------------------------------------
>>> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
>>> With Perforce, you get hassle-free workflows. Merge that actually works.
>>> Faster operations. Version large binaries. Built-in WAN optimization and the
>>> freedom to use Git, Perforce or both. Make the move to Perforce.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries. Built-in WAN optimization and the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> --
> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>
> -- Antonio Alducin --
|
|
From: Skip M. <sk...@po...> - 2014-03-06 21:03:23
|
On Thu, Mar 6, 2014 at 2:51 PM, Nelle Varoquaux
<nel...@gm...> wrote:
> The convention is to use a simple _.
>
> mode, _, dev, nlink, uid, gid, size, _, _, _ = os.stat("/etc/hosts")
Which is "pylint-compliant", but removes any description to future
readers (who might decide to use them) what the meaning of those
various unused values are.
Skip
|
|
From: Joe K. <jki...@ge...> - 2014-03-06 21:24:41
|
On Thu, Mar 6, 2014 at 3:03 PM, Skip Montanaro <sk...@po...> wrote:
> On Thu, Mar 6, 2014 at 2:51 PM, Nelle Varoquaux
> <nel...@gm...> wrote:
> > The convention is to use a simple _.
> >
> > mode, _, dev, nlink, uid, gid, size, _, _, _ = os.stat("/etc/hosts")
>
> Which is "pylint-compliant", but removes any description to future
> readers (who might decide to use them) what the meaning of those
> various unused values are.
>
Just to bikeshed a bit: There are common cases where a bare "_" really is a
good solution. E.g.
something = [object() for _ in range(10)]
It's immediately clear a) what "_" is, and b) that it's unused. "for _i in
range(10)" is more jarring in that particular case, i.m.h.o.
I do agree that "_descriptive_name" is better in many situations.
I'd just argue for a "prefer this, but use your best judgement" type
guideline rather than a strict rule.
Then again, I'm not actively involved in development, so I probably
shouldn't hold too much of an opinion either way.
Cheers,
-Joe
|
|
From: Nelle V. <nel...@gm...> - 2014-03-06 21:13:19
|
On 6 March 2014 22:03, Skip Montanaro <sk...@po...> wrote:
> On Thu, Mar 6, 2014 at 2:51 PM, Nelle Varoquaux
> <nel...@gm...> wrote:
>> The convention is to use a simple _.
>>
>> mode, _, dev, nlink, uid, gid, size, _, _, _ = os.stat("/etc/hosts")
>
> Which is "pylint-compliant", but removes any description to future
> readers (who might decide to use them) what the meaning of those
> various unused values are.
The opposite also holds: personally, my brain shuts down when I see an
underscore, because I know those values aro no use in this context. If
there are variables names that aren't use, it confuses me, and I try
to understand where they are use.
If I need to understand what exactly os.stat returns, I just read the
documentation, and not rely on some possibly misleading variable
names.
We can debate hours whether these conventions are justified or not.
It all comes down to what's your habit.
>From the google style guide (pylint section):
Unused argument warnings can be suppressed by using `_' as the
identifier for the unused argument or prefixing the argument name with
`unused_'. In situations where changing the argument names is
infeasible, you can mention them at the beginning of the function. For
example:
def foo(a, unused_b, unused_c, d=None, e=None):
_ = d, e
return a
>
> Skip
|
|
From: Skip M. <sk...@po...> - 2014-03-06 21:24:03
|
On Thu, Mar 6, 2014 at 3:13 PM, Nelle Varoquaux <nel...@gm...> wrote: > If I need to understand what exactly os.stat returns, I just read the > documentation, and not rely on some possibly misleading variable > names. Despite our wish that it wasn't so, it is likely that there is far more undocumented than documented code out in the wild, or behind firewalls where we can't see it. I just used os.stat as an example of a well-known function that returns multiple values. (Precisely, so people wouldn't have to run to the documentation or that I would have to provide a more-fleshed-out example.) In my experience, there's no real need to be intentionally obscure by not giving a variable a meaningful, whether or not you intend/expect to use it. Besides, open source code can serve as a living example of good coding practices. Might as well do our best in that regard. Just sayin'... Skip |
|
From: Todd <tod...@gm...> - 2014-03-07 11:08:29
|
On Mar 6, 2014 10:24 PM, "Skip Montanaro" <sk...@po...> wrote: > > On Thu, Mar 6, 2014 at 3:13 PM, Nelle Varoquaux > <nel...@gm...> wrote: > > If I need to understand what exactly os.stat returns, I just read the > > documentation, and not rely on some possibly misleading variable > > names. > > Despite our wish that it wasn't so, it is likely that there is far > more undocumented than documented code out in the wild, or behind > firewalls where we can't see it. I just used os.stat as an example of > a well-known function that returns multiple values. (Precisely, so > people wouldn't have to run to the documentation or that I would have > to provide a more-fleshed-out example.) In my experience, there's no > real need to be intentionally obscure by not giving a variable a > meaningful, whether or not you intend/expect to use it. Besides, open > source code can serve as a living example of good coding practices. > Might as well do our best in that regard. > > Just sayin'... > > Skip Whether it is necessarily the optimal choice, I think there is something to be said for following established conventions. Besides the fact that IDEs complain if you don't, it makes it easier for outside contributors to understand what it's going on. |
|
From: Chris B. <chr...@no...> - 2014-03-06 21:59:28
|
On Thu, Mar 6, 2014 at 1:23 PM, Skip Montanaro <sk...@po...> wrote: > Despite our wish that it wasn't so, it is likely that there is far > more undocumented than documented code out in the wild, or behind > firewalls where we can't see it. Well, then you're hosed anyway -- relying on the name of an unused variable using a call for your docs is, shall we say not very robust. In my experience, there's no > real need to be intentionally obscure by not giving a variable a > meaningful, whether or not you intend/expect to use it. Besides, open > source code can serve as a living example of good coding practices. > Might as well do our best in that regard. > then use "unused_meaningful_name" it looks like pylint, anyway, will accept that. Or is the goal here to come to a consensus for MPL style? If so, I'm +1 on "_", and -0 on unused_meaningful_name -Chris > > Just sayin'... > > Skip > > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to > Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and > the > freedom to use Git, Perforce or both. Make the move to Perforce. > > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
|
From: Skip M. <sk...@po...> - 2014-03-06 22:07:01
|
On Thu, Mar 6, 2014 at 3:58 PM, Chris Barker <chr...@no...> wrote: > it looks like pylint, anyway, will accept that. Yes, pylint used to only accept a leading underscore by default as a flag that a variable was unused. When I switched from pychecker to pylint a few years ago, all my carefully crafted "unused_" variables got flagged by pylint. I suggested adding that as another default prefix, and they agreed. Skip |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X