Hi,
>> I hope new stuff will follow only one naming style. And now we should
>> (or one person :-) should) decide which one.
>
> I guess my point boils down to, we already did decide 4 years ago.
> Let's stick with what we've got.
Ok, then let's stick with lower_case and check this if new librar
On Thu, 2005-12-15 at 11:22 +0100, [EMAIL PROTECTED]
wrote:
> I hope new stuff will follow only one naming style. And now we should
> (or one person :-) should) decide which one.
I guess my point boils down to, we already did decide 4 years ago.
Let's stick with what we've got.
-Barry
signatu
Hi,
>>> Too late. I don't think the diversity is all that distracting.
>> I disagree. One of the things that Java got very much right was to
>> specify, from the very beginning, what the preferred conventions are
>> for naming conventions. (Packages in lowercase, Classes in CapWords,
>> methods an
Hi,
>>> Too late. I don't think the diversity is all that distracting.
>> I disagree. One of the things that Java got very much right was to
>> specify, from the very beginning, what the preferred conventions are
>> for naming conventions. (Packages in lowercase, Classes in CapWords,
>> methods an
On 12/14/05, Michael Chermside <[EMAIL PROTECTED]> wrote:
> Guido writes:
> > Actually this (function, method and ivar names) is such a contentious
> > issue that I think the style guide should explicitly allow all
> > two/three styles and recommend to be consistent within a class, module
> > or pa
On Wed, 2005-12-14 at 10:17 -0800, Guido van Rossum wrote:
> Actually this (function, method and ivar names) is such a contentious
> issue that I think the style guide should explicitly allow all
> two/three styles and recommend to be consistent within a class, module
> or package.
My own feeling
On Wed, 2005-12-14 at 09:08 -0800, Michael Chermside wrote:
> Wolfgang writes:
> > We need a clear style for function and method names
> > now std lib uses "foo_bar" sometimes "foobar"
> > and sometimes "fooBar".
>
> Personally, I prefer "fooBar". But I try not to use it in python
> code... I try
Guido writes:
> Actually this (function, method and ivar names) is such a contentious
> issue that I think the style guide should explicitly allow all
> two/three styles and recommend to be consistent within a class, module
> or package.
Hurray! Now I can go back to using capWords for functions, m
On 12/14/05, Wolfgang <[EMAIL PROTECTED]> wrote:
> Hello,
>
> PEP 8 for function and method names:
> -
> Function Names
>
>Function names should be lowercase, possibly with words separated by
>underscores to improve readability. mixedCase is allowed only in
>contexts wh
Wolfgang writes:
> We need a clear style for function and method names
> now std lib uses "foo_bar" sometimes "foobar"
> and sometimes "fooBar".
Personally, I prefer "fooBar". But I try not to use it in python
code... I try to always use "foo_bar" because that's what PEP 8 says.
I believe recall
Hi,
Michael Hoffman wrote:
> [Wolfgang]
>
>> Or should we switch to camelCase with lowercase first letter ?
>> As most other Languages prefer this (Java, C#, C++, ...)
>
> They also use curly braces instead of indentation to indicate block
> structure. Maybe we should switch to that too.
Or BE
[Wolfgang]
> Or should we switch to camelCase with lowercase first letter ?
> As most other Languages prefer this (Java, C#, C++, ...)
They also use curly braces instead of indentation to indicate block
structure. Maybe we should switch to that too.
--
Michael Hoffman <[EMAIL PROTECTED]>
Europe
Hello,
PEP 8 for function and method names:
-
Function Names
Function names should be lowercase, possibly with words separated by
underscores to improve readability. mixedCase is allowed only in
contexts where that's already the prevailing style (e.g. threading.py),
13 matches
Mail list logo
