On Thu, 21 Oct 2010 20:04:10 +0100, Arnaud Delobelle wrote:
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Thu, 21 Oct 2010 11:37:36 +0200, Jean-Michel Pichavant wrote:
By the way:
xCoordinate, yCoordinate, zCoordinate = polygon.nextPointCoordinates()
Coordinates are
On Thu, 21 Oct 2010 17:20:54 +0200, Jean-Michel Pichavant wrote:
While I totally understand why some ppl prefer to use short names,
Oh the irony.
I
really don't see the point in saying that because any information can be
wrong, we should stop giving any.
It's only in your fevered
On Thu, 21 Oct 2010 10:47:28 -0400, Mel wrote:
Long variable names can lie; they share this ability with comments. The
one study** I've seen of newbie errors observed the #1 error being as
assumption that descriptive variable names could somehow replace
computation, e.g. that if you called a
Seebs wrote:
On 2010-10-21, Jean-Michel Pichavant jeanmic...@sequans.com wrote:
Let me quote the paper I linked in the previous post:
list1 = []
for x in theList:
if x[0] == 4:
list1 += x;
return list1
compare it to:
flaggedCells = []
for cell in theBoard:
if
Seebs wrote:
On 2010-10-21, Jean-Michel Pichavant jeanmic...@sequans.com wrote:
It can be short if descriptive:
for o, c in cars:
park(o)
phone(c)
for owner, car in cars: # by just using meaningful names you give the
info to the reader that you expect cars to be
On 2010-10-22, Jean-Michel Pichavant jeanmic...@sequans.com wrote:
Seebs wrote:
The one that brought this up, though, was except FooError, e:, and in
that case, there is no need for any further description; the description
is provided by the except, and e is a perfectly reasonable, idiomatic,
On 2010-10-22, Jean-Michel Pichavant jeanmic...@sequans.com wrote:
Seebs wrote:
On 2010-10-21, Jean-Michel Pichavant jeanmic...@sequans.com wrote:
list1 = []
for x in theList:
if x[0] == 4:
list1 += x;
return list1
flaggedCells = []
for cell in theBoard:
if
I'm all for descriptive names, but there's a great deal of benefit to
knowing when a descriptive name will help, and when all you need is a
variable which will be quickly recognized.
Compare:
[theValueInTheList.func() forTheValueInTheList in theList]
[x.func() for x in list]
One of these is
On 2010-10-22, Jean-Michel Pichavant jeanmic...@sequans.com wrote:
I'm all for descriptive names, but there's a great deal of benefit to
knowing when a descriptive name will help, and when all you need is a
variable which will be quickly recognized.
Compare:
[theValueInTheList.func()
On 10/20/10 22:09, Seebs wrote:
On 2010-10-20, Matteo Landilandima...@gmail.com wrote:
Another situation in which I needed to disable such kind of warnings
is while working with graphics modules.
I often use variable names such as x, y, z for coordinates, or r,g,b for colors.
Would longer
Steven D'Aprano wrote:
On Wed, 20 Oct 2010 12:47:02 +0200, Jean-Michel Pichavant wrote:
except ValueError, e:
Use meaningful names, this is so important. 'e' is not meaningful.
'exception' would be slighly better.
While I agree with everything else you had to say, I have to take
Martin P. Hellwig wrote:
On 10/20/10 22:09, Seebs wrote:
On 2010-10-20, Matteo Landilandima...@gmail.com wrote:
Another situation in which I needed to disable such kind of warnings
is while working with graphics modules.
I often use variable names such as x, y, z for coordinates, or r,g,b
On 2010-10-21, Jean-Michel Pichavant jeanmic...@sequans.com wrote:
In the middle of thousand lines of code, when you are reviewing
or debugging, the later is better TMO, the point is that x, y,
z = is only easy to read during the assignement. Consider this:
x, y, z = p.nextpoint()
[snip a
On Thu, 21 Oct 2010 11:37:36 +0200, Jean-Michel Pichavant wrote:
In the middle of thousand lines of code,
If you have a function that is a thousand lines of code long, I don't
care what you name the variables, you won't be able to keep it straight
in your head.
This is one of the reasons
On Thu, 21 Oct 2010 12:49:47 +, Neil Cerutti wrote:
_The Practice of Programming_ has this right. In general the bigger the
scope of a variable, the longer and more descriptive should be its name.
In a small scope, a big name is mostly noise.
Thank you! The scope of the variable is an
On Thu, 21 Oct 2010 11:27:57 +0200, Jean-Michel Pichavant wrote:
There is another important point: the time where code size matters is
over.
That's ridiculous. Which would you rather write?
import os
if os.path.exists(myfile):
print open(myfile).read()
or this?
import the module
You
won't be that happy everyone wrote their mail in this list like a mobile
text message, if u c what I mean.
I never suggested that. What I am trying to get across is that long names
are not automatically better than short names, and even one letter names
can be as good or better
Steven D'Aprano wrote:
On Thu, 21 Oct 2010 12:49:47 +, Neil Cerutti wrote:
_The Practice of Programming_ has this right. In general the bigger the
scope of a variable, the longer and more descriptive should be its name.
In a small scope, a big name is mostly noise.
Thank you! The
Mel wrote:
Steven D'Aprano wrote:
On Thu, 21 Oct 2010 12:49:47 +, Neil Cerutti wrote:
_The Practice of Programming_ has this right. In general the bigger the
scope of a variable, the longer and more descriptive should be its name.
In a small scope, a big name is mostly noise.
On 2010-10-21, Jean-Michel Pichavant jeanmic...@sequans.com wrote:
So If I get you right, because comments can lie, we should stop
using comments?
No, but use comment judiciously. Kernighan and Pike (_The
Practice of Programming_) recommend writing your code to require
as little comment as
On 2010-10-21, Martin P. Hellwig martin.hell...@dcuktec.org wrote:
Although intuitively I would say the shorthand, however that is
depending on the context being me knowing at least the basics of 3d
spaces and having the pre-warning that you are going to mention
something with either
On 2010-10-21, Jean-Michel Pichavant jeanmic...@sequans.com wrote:
In the middle of thousand lines of code, when you are reviewing or
debugging, the later is better TMO, the point is that x, y, z = is only
easy to read during the assignement.
Bull.
x, y, z = p.nextpoint()
[snip a dozen of
On 2010-10-21, Jean-Michel Pichavant jeanmic...@sequans.com wrote:
Let me quote the paper I linked in the previous post:
list1 = []
for x in theList:
if x[0] == 4:
list1 += x;
return list1
compare it to:
flaggedCells = []
for cell in theBoard:
if cell[STATUS_VALUE] ==
On 2010-10-21, Jean-Michel Pichavant jeanmic...@sequans.com wrote:
It can be short if descriptive:
for o, c in cars:
park(o)
phone(c)
for owner, car in cars: # by just using meaningful names you give the
info to the reader that you expect cars to be a list of tuple (owner, car)
Steven D'Aprano st...@remove-this-cybersource.com.au writes:
On Thu, 21 Oct 2010 11:37:36 +0200, Jean-Michel Pichavant wrote:
By the way:
xCoordinate, yCoordinate, zCoordinate = polygon.nextPointCoordinates()
Coordinates are pairs or triples of *ordinates* (no co). You can't have
an x
Seebs wrote:
On 2010-10-19, Martin P. Hellwig martin.hell...@dcuktec.org wrote:
Speaking without context here, so take it with as much salt as required
;-), it is not that unusual. However there are some things to consider,
for example are all these attributes related to each other? If so
On 2010-10-20, Jean-Michel Pichavant jeanmic...@sequans.com wrote:
except ValueError, e:
Use meaningful names, this is so important.
It's important, but meaning can come from idiom, not from the word used.
'e' is not meaningful.
Sure it is. It's like i for a loop index.
There's a reason
On Wed, 20 Oct 2010 12:47:02 +0200, Jean-Michel Pichavant wrote:
except ValueError, e:
Use meaningful names, this is so important. 'e' is not meaningful.
'exception' would be slighly better.
While I agree with everything else you had to say, I have to take
exception to this comment [pun
Another situation in which I needed to disable such kind of warnings
is while working with graphics modules.
I often use variable names such as x, y, z for coordinates, or r,g,b for colors.
Would longer names make the reader's life easier?
Best regards,
Matteo
On Wed, Oct 20, 2010 at 9:37 PM,
On 2010-10-20, Matteo Landi landima...@gmail.com wrote:
Another situation in which I needed to disable such kind of warnings
is while working with graphics modules.
I often use variable names such as x, y, z for coordinates, or r,g,b for
colors.
Would longer names make the reader's life
Seebs usenet-nos...@seebs.net writes:
Interesting point. Which is really easier to read:
x, y, z = p.nextpoint()
xCoordinate, yCoordinate, zCoordinate = polygon.nextPointCoordinates()
The latter uses camelCase, so it's horrible right out of the gate :-)
--
\ “The
So, I'm messing around with pylint. Quite a lot of what it says
is quite reasonable, makes sense to me, and all that.
There's a few exceptions.
One: I am a big, big, fan of idiomatic short names where appropriate.
For instance:
catch something, e:
I don't want a long, verbose, name --
On Tue, 19 Oct 2010 19:57:36 +, Seebs wrote:
So, I'm messing around with pylint. Quite a lot of what it says is
quite reasonable, makes sense to me, and all that.
There's a few exceptions.
One: I am a big, big, fan of idiomatic short names where appropriate.
For instance:
On 19.10.2010 21:57, Seebs wrote:
So, I'm messing around with pylint. Quite a lot of what it says
is quite reasonable, makes sense to me, and all that.
There's a few exceptions.
One: I am a big, big, fan of idiomatic short names where appropriate.
For instance:
catchsomething, e:
I
Just to be pedantic (or maybe even helpful), the use of the comma
after the exception is deprecated in favor of 'as.'
So:
except ValueError as ex:
not:
except ValueError, ex:
I don't know how far back in Python versions this syntax reaches, but
if yours supports it then it's probably a good
On 2010-10-19, Steven D'Aprano st...@remove-this-cybersource.com.au wrote:
On Tue, 19 Oct 2010 19:57:36 +, Seebs wrote:
One: I am a big, big, fan of idiomatic short names where appropriate.
For instance:
catch something, e:
That would be except, not catch.
Er, yeah, that.
Well,
On 2010-10-19, Shawn Milochik sh...@milochik.com wrote:
Just to be pedantic (or maybe even helpful), the use of the comma
after the exception is deprecated in favor of 'as.'
Not in code that has to run on older Pythons.
I'm pretty sure I have to work with everything from 2.4 to 2.6 or so.
On 10/19/2010 3:57 PM, Seebs wrote:
So, I'm messing around with pylint. Quite a lot of what it says
is quite reasonable, makes sense to me, and all that.
There's a few exceptions.
...
So am I going to be laughed out of the room if I just let a class have
eight instance attributes, or use a
On 10/19/10 20:57, Seebs wrote:
So, I'm messing around with pylint. Quite a lot of what it says
is quite reasonable, makes sense to me, and all that.
There's a few exceptions.
Well, as with all styles IMHO, if there is a _good_ reason to break it,
then by all means do, but you might want to
On 10/19/2010 5:43 PM, Seebs wrote:
That reminds me, though. Speaking of deprecation, I have:
from string import Template
(see PEP 292 or so?), and pylint says Uses of a deprecated module 'string',
but I don't know of a way to get Template except by doing that.
A buggy PyLint is
On 2010-10-19, Martin P. Hellwig martin.hell...@dcuktec.org wrote:
Well, as with all styles IMHO, if there is a _good_ reason to break it,
then by all means do, but you might want to consider putting in a
comment why you did that and add the #pylint: disable-msg=message_id
on that line. If
Seebs usenet-nos...@seebs.net writes:
So, I'm messing around with pylint. Quite a lot of what it says
is quite reasonable, makes sense to me, and all that.
There's a few exceptions.
While the exceptions will no doubt lead to fascinating discussions, I'll
offer a somewhat related piece of
On 10/19/10 23:36, Seebs wrote:
cut
It seems like a
very odd measure of complexity; is it really that unusual for objects to have
more than seven meaningful attributes?
Speaking without context here, so take it with as much salt as required
;-), it is not that unusual. However there are some
On 20.10.2010 00:36, Seebs wrote:
On 2010-10-19, Martin P. Hellwigmartin.hell...@dcuktec.org wrote:
Well, as with all styles IMHO, if there is a _good_ reason to break it,
then by all means do, but you might want to consider putting in a
comment why you did that and add the #pylint:
On 2010-10-19, Martin P. Hellwig martin.hell...@dcuktec.org wrote:
Speaking without context here, so take it with as much salt as required
;-), it is not that unusual. However there are some things to consider,
for example are all these attributes related to each other? If so
wouldn't it be
On 2010-10-19, Ben Finney ben+pyt...@benfinney.id.au wrote:
Tools like pylint are far more useful if every message they emit is
something that you must deal with, rather than ignore every time you see
it. That way, it's feasible to get the output to no messages at all, and
have a defensible
On 2010-10-19, Alexander Kapps alex.ka...@web.de wrote:
The general idea is, that modules, classes, methods, and functions
should be small so they are better reusable, manageable and
understandable.
Makes sense.
If you have a huge class or function with many
attributes or local
Seebs usenet-nos...@seebs.net writes:
I'm pretty much mystified by a claim that something with seven
instance attributes is too complicated.
It's a code smell. Many discrete attributes is a sign that the design
can be improved by combining related attributes into a complex type.
It's pretty
On 2010-10-20, Ben Finney ben+pyt...@benfinney.id.au wrote:
It's a code smell. Many discrete attributes is a sign that the design
can be improved by combining related attributes into a complex type.
Ahh.
I think that makes sense. In this case, I don't think it's worth it,
but I can see why it
49 matches
Mail list logo
