I'm hoping to return to more active status with a change in jobs now and
finally finishing off the thesis.
I should be at SciPy and would very much be interested in sticking around
to discuss development. (Though I should probably make sure the job will
pay for me to stick around for the sprints..
On Thu, Mar 6, 2014 at 3:58 PM, Chris Barker 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_"
On Thu, Mar 6, 2014 at 1:23 PM, Skip Montanaro 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 va
I am awaiting approval from my superiors to pay for me to go this year. I
plan to split out my Anatomy of Matplotlib tutorial into two levels. If
that works out and both tutorials get accepted, then I would imagine that I
could spend an extra day. Would this extra day be before or after the week
of
On Thu, Mar 6, 2014 at 3:03 PM, Skip Montanaro wrote:
> On Thu, Mar 6, 2014 at 2:51 PM, Nelle Varoquaux
> 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
On Thu, Mar 6, 2014 at 3:13 PM, Nelle Varoquaux
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 docu
On 6 March 2014 22:03, Skip Montanaro wrote:
> On Thu, Mar 6, 2014 at 2:51 PM, Nelle Varoquaux
> 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
> read
On Thu, Mar 6, 2014 at 2:51 PM, Nelle Varoquaux
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 tho
On 6 March 2014 21:53, Federico Ariza 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
> wrote:
>> On 6 March 2014 21:47,
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
Nelle
Is that written somewhere?
On Thu, Mar 6, 2014 at 3:51 PM, Nelle Varoquaux
wrote:
> On 6 March 2014 21:47, Skip Montanaro wrote:
>> On Thu, Mar 6, 2014 at 2:38 PM, Ryan May wrote:
>>> I don't think a leading _ is the way to go, because that's a common
>>> convention for internal class va
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 wrote:
> On Thu, Mar 6, 2014 at 2:38 PM, Ryan May wrote:
>> I don't think a leading _ is the way to go, because that's a common
>> convention
On 6 March 2014 21:47, Skip Montanaro wrote:
> On Thu, Mar 6, 2014 at 2:38 PM, Ryan May 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 le
On Thu, Mar 6, 2014 at 2:38 PM, Ryan May 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 attribute
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 havin
On Thu, Mar 6, 2014 at 7:47 AM, Federico Ariza 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 pyli
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 m
On 2014/02/27 6:28 AM, Michael Droettboom wrote:
> How many matplotlib developers are planning to attend SciPy this year?
Most likely I will not.
Eric
>
> If we used some of our funds to support an extra hotel night, would any
> of you be interested in spending an extra day for a "matplotlib
> d
Hello,
I've not been very active in the development of matplotlib these past
few months, but I'll answer anyways.
I'll be at Scipy this year, but I won't be able to stay after the
sprints. I have another conference right after.
Cheers,
N
On 2 March 2014 04:37, Thomas Caswell wrote:
> I am still
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 w
20 matches
Mail list logo
