method names nounVerb or verbNoun
Wanderer
verbNoun?
For example voltageGet or getVoltage? getVoltage sounds more normal,
but voltageGet is more like voltage.Get. I seem to mix them and I
should probably pick one way and stick with it.
Thanks
Gerald Britton
> http://mail.python.org/mailman/listinfo/python-list
>
I'd say noun_verb (note the underscore in accordance with the style
guide in PEP 8):
http://www.python.org/dev/peps/pep-0008/
Function Names
Function names should be lowercase, with words separated by underscores
as necessary to improve readability.
mixedCase is allowed only in contexts where that's already the
prevailing style (e.g. threading.py), to retain backwards compatibility.
--
Gerald Britton
MRAB
Chris Rebert
Use properties[1] and just call it `voltage`. Python is not Java [2];
explicit getters/setters are unpythonic.
[1] http://docs.python.org/library/functions.html#property
[2] http://dirtsimple.org/2004/12/python-is-not-java.html
Cheers,
Chris
--
http://blog.rebertia.com
Wanderer
Maybe I'm not using Get right either. I'm wrapping functions.
def AbbeGet(self, Lens):
"""
Get the Abbe Number V for the material
where
V = (Nd - 1)/(Nf - Nc)
where the Index of Refractions are
Nd at the Fraunhofer D line 0.5892um
Nf at the Fraunhofer F line 0.4861um
Nc at the Fraunhofer C line 0.6563um
"""
Nd = Lens.Mat.NtGet(0.5892)
Nf = Lens.Mat.NtGet(0.4861)
Nc = Lens.Mat.NtGet(0.6563)
if (Nf - Nc) != 0:
V = (Nd - 1)/(Nf - Nc)
else:
V = 1e6
return V
# end AbbeGet
Alf P. Steinbach
Consider this piece of code:
x = 2*sin( angle )
versus this:
x = 2*get_sin( angle )
or this:
x = 2*sin_get( angle )
Cheers & hth.,
- Alf
Chris Rebert
> On Feb 5, 3:26 pm, Chris Rebert <c...@rebertia.com> wrote:
>> On Fri, Feb 5, 2010 at 11:53 AM, Wanderer <wande...@dialup4less.com> wrote:
>> > Which is the more accepted way to compose method names nounVerb or
>> > verbNoun?
>>
>> > For example voltageGet or getVoltage? getVoltage sounds more normal,
>> > but voltageGet is more like voltage.Get. I seem to mix them and I
>> > should probably pick one way and stick with it.
>>
>> Use properties[1] and just call it `voltage`. Python is not Java [2];
>> explicit getters/setters are unpythonic.
>>
>> [1]http://docs.python.org/library/functions.html#property
>
>
> def AbbeGet(self, Lens):
> """
> Get the Abbe Number V for the material
> where
> V = (Nd - 1)/(Nf - Nc)
> where the Index of Refractions are
> Nd at the Fraunhofer D line 0.5892um
> Nf at the Fraunhofer F line 0.4861um
> Nc at the Fraunhofer C line 0.6563um
> """
>
> Nd = Lens.Mat.NtGet(0.5892)
> Nf = Lens.Mat.NtGet(0.4861)
> Nc = Lens.Mat.NtGet(0.6563)
>
> if (Nf - Nc) != 0:
> V = (Nd - 1)/(Nf - Nc)
> else:
> V = 1e6
>
> return V
This isn't even really a method; you don't refer to "self" in the body
at all. Why isn't it just a function?
Wanderer
Okay, I guess it should be a function called abbe() instead of a
method called AbbeGet(). That should solve the problem of trying to
remember whether I called it GetAbbe or AbbeGet.
Thanks
Steven D'Aprano
> Which is the more accepted way to compose method names nounVerb or
> verbNoun?
>
> For example voltageGet or getVoltage? getVoltage sounds more normal,
+0.5 for getVoltage
+1 get_voltage
-1 for voltageGet or voltage_get
> but
> voltageGet is more like voltage.Get.
According to PEP 8, the style guide for the standard library, method
names should use lowercase initial letter, so you should have
voltage.get. Following PEP 8 isn't compulsory, but it is recommended
unless you want a bunch of busy-body coders telling you you need to
follow PEP 8 :)
> I seem to mix them and I should
> probably pick one way and stick with it.
Yes.
--
Steven
Steven D'Aprano
> On Fri, Feb 5, 2010 at 11:53 AM, Wanderer <wand...@dialup4less.com>
> wrote:
>> Which is the more accepted way to compose method names nounVerb or
>> verbNoun?
>>
>> For example voltageGet or getVoltage? getVoltage sounds more normal,
>> but voltageGet is more like voltage.Get. I seem to mix them and I
>> should probably pick one way and stick with it.
>
> Use properties[1] and just call it `voltage`. Python is not Java [2];
> explicit getters/setters are unpythonic.
But sometimes you still need methods or functions of the form verb_noun.
For instance, if getting or setting the voltage is an expensive
operation, you don't want to fool the user into thinking it is a cheap
attribute access. Or get_voltage might be a stand-alone function rather
than a method. Or the getter might allow additional arguments.
The admonition to avoid getters and setters isn't meant to prohibit *any*
method which has a get/set in the name (whether implicit or explicit).
It's meant as an antidote to the Java idiom of making *every* attribute
private and accessing them via getters/setters, even when all they do is
merely get/set the contents of the attribute.
--
Steven
Chris Rebert
<st...@remove-this-cybersource.com.au> wrote:
> On Fri, 05 Feb 2010 12:26:38 -0800, Chris Rebert wrote:
>> On Fri, Feb 5, 2010 at 11:53 AM, Wanderer <wand...@dialup4less.com>
>> wrote:
>>> Which is the more accepted way to compose method names nounVerb or
>>> verbNoun?
>>>
>>> For example voltageGet or getVoltage? getVoltage sounds more normal,
>>> but voltageGet is more like voltage.Get. I seem to mix them and I
>>> should probably pick one way and stick with it.
>>
>> Use properties[1] and just call it `voltage`. Python is not Java [2];
>> explicit getters/setters are unpythonic.
>
> But sometimes you still need methods or functions of the form verb_noun.
True, but when the verb is "get" and you're using Python, your design
probably merits another going-over. If the OP hadn't used "get" as
their example, I would have answered significantly differently.
> For instance, if getting or setting the voltage is an expensive
> operation, you don't want to fool the user into thinking it is a cheap
> attribute access.
I strongly disagree with this rationale as it violates the Uniform
Access Principle
(http://en.wikipedia.org/wiki/Uniform_access_principle). Though I
concede Python's builtins don't adhere to the UAP.
> Or get_voltage might be a stand-alone function rather
> than a method.
The OP originally said quite explicitly it was a method in their
original post. (Though they since wisely changed their code structure
so it's not.)
> Or the getter might allow additional arguments.
True; but before the OP posted the actual function body, there was no
way to know whether it did. Lacking such info, I assumed the simplest
and most frequent case, namely that it didn't take any args.
> The admonition to avoid getters and setters isn't meant to prohibit *any*
> method which has a get/set in the name (whether implicit or explicit).
> It's meant as an antidote to the Java idiom of making *every* attribute
> private and accessing them via getters/setters, even when all they do is
> merely get/set the contents of the attribute.
True. Again, before the OP posted the method body, there was no way to
know it wasn't a trivial Java-esque getter.
Carl Banks
> On Fri, Feb 5, 2010 at 2:45 PM, Steven D'Aprano
>
> <st...@remove-this-cybersource.com.au> wrote:
> > For instance, if getting or setting the voltage is an expensive
> > operation, you don't want to fool the user into thinking it is a cheap
> > attribute access.
>
> I strongly disagree with this rationale as it violates the Uniform
> Access Principle
> (http://en.wikipedia.org/wiki/Uniform_access_principle). Though I
> concede Python's builtins don't adhere to the UAP.
And I strongly disagree with the Uniform Access Principle. I want my
accesses to an object to be explicitly "data-like" or "method-like",
even if
Based on the Wikipedia page, Meyer's main reason behind UAP seems to
be to minimize the need to break interfaces: the UAP is a means to an
end. Python achieves that end without the conforming to UAP,
therefore it doesn't need it, and there's no reason to adhere to it.
Carl Banks
Wanderer
Actually I decided it still should be a method, just not of doublet
but of Lens. so the calls change from
V1 = self.AbbeGet(Lens1)
V2 = self.AbbeGet(Lens2)
V1 = self.Lens1.abbe()
V2 = self.Lens2.abbe()
cjw
rules.
Colin W.
Martin P. Hellwig
For me personally I do the following:
spam_get/spam_set; might be preferred if you have more spam_* functions
(i.e. spam_del, spam_eat, etc.)
set_spam/get_spam; is I think reasonable if you have also a *_ham
function (i.e. set_ham, get_ham).
Funny thing for me is that when I have both spam_* & *_ham naming, I
usually rethink my approach and split it out to separate classes/modules.
Please note that this is at the moment a personal, uneducated, never
really thought about it, preference. Meaning it is very likely that with
some more insight there is a good chance that I find my approach in
retrospect flawed.
--
mph