Updates:
Labels: -Milestone-Release0.7.2
Comment #47 on issue 1757 by asmeu...@gmail.com: coding style
http://code.google.com/p/sympy/issues/detail?id=1757
This is related to issue 1456.
--
You received this message because you are subscribed to the Google Groups
"sympy-patches" group.
Updates:
Labels: -Milestone-Release0.7.0 Milestone-Release0.7.1
Comment #45 on issue 1757 by asmeurer: coding style
http://code.google.com/p/sympy/issues/detail?id=1757
(No comment was entered for this change.)
--
You received this message because you are subscribed to the Google Groups
Comment #44 on issue 1757 by asmeurer: coding style
http://code.google.com/p/sympy/issues/detail?id=1757
In any case, this should be considered a guideline that can be broken if,
but only if, there is a good reason to do so.
OK. I agree. So this means that it should *not* go in the quality
Comment #43 on issue 1757 by Vinzent.Steinberg: coding style
http://code.google.com/p/sympy/issues/detail?id=1757
like "def __add__(a, b):"
In this case I'd rather use 'self' and 'other', because you might have to
normalize 'other', if you want to support more than just instances of your
Comment #42 on issue 1757 by ronan.l...@gmail.com: coding style
http://code.google.com/p/sympy/issues/detail?id=1757
I disagree with 1) because in many cases it's more natural to not use
self.
I really don't think there are "many cases". I agree it's debatable for
some special methods like
Comment #41 on issue 1757 by ronan.l...@gmail.com: coding style
http://code.google.com/p/sympy/issues/detail?id=1757
'self' isn't just any function argument, it has a (purely conventional)
specific meaning. Rebinding it breaks the implicit promises carried by the
name (e.g. the object named
Comment #40 on issue 1757 by asmeurer: coding style
http://code.google.com/p/sympy/issues/detail?id=1757
Yeah, self is nothing special in Python; it's just a conventional name for
the first argument of methods that is automatically given as object in
object.method(…). It's not like by doing
Comment #39 on issue 1757 by smichr: coding style
http://code.google.com/p/sympy/issues/detail?id=1757
grep for "self = " and you'll find some places where it happens in current
sympy.
I would do it when I intend to modify self and return a new value. A
trivial example, but in the spirit o
Comment #38 on issue 1757 by asmeurer: coding style
http://code.google.com/p/sympy/issues/detail?id=1757
I see. Yes, that is probably a bad idea, because then you lose access to
self. But does it really happen so often that we need to test for it? I
have never seen anything like that befo
Comment #37 on issue 1757 by ronan.l...@gmail.com: coding style
http://code.google.com/p/sympy/issues/detail?id=1757
What do you mean "don't modify self in a method"?
More precisely, it's "don't rebind the first argument of a method
(usually 'self' or 'cls') inside the method".
It means th
Comment #36 on issue 1757 by asmeurer: coding style
http://code.google.com/p/sympy/issues/detail?id=1757
What do you mean "don't modify self in a method"?
And by the way, the first argument of class methods should be "cls",
not "self".
--
You received this message because you are subscribed
Comment #35 on issue 1757 by mattpap: coding style
http://code.google.com/p/sympy/issues/detail?id=1757
I disagree with 1) because in many cases it's more natural to not use self.
Even in Python's standard library self is not always used as the first
argument, e.g. in Fraction class from fra
Comment #34 on issue 1757 by smichr: coding style
http://code.google.com/p/sympy/issues/detail?id=1757
Here are some other issues that have come up and can be discussed:
1) always name the first argument of a method "self"
2) don't modify self in a method.
--
You received this message because
13 matches
Mail list logo
