Re: [Python-Dev] PEP 8 updates/clarifications, function/method style
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 libraries were added to std lib. Possible add a note to not forbid the use of cameCase in external libraries ? bye by Wolfgang ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications, function/method style
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 and variables in lowerCapWords, constants optionally in ALL_CAPS. Abbrevs avoided, acronyms have all letters capitalized, eg: SimpleHTTPServer.) The conventions are nearly universally followed, and as a result in java I always know how to spell things. I never have to remember whether it's myDict.hasKey() and myDict.popitem() or myDict.has_key() and myDict.popItem(). Haskell goes too far -- they REQUIRE a certain convention as part of the language... this prevents breaking the rules on purpose (eg: wrapping a library from another language, or using an object with attributes to represent an XML node with child nodes). I agree completely with this. I might remember the name of a method, but I don't always remember the capping and the possible use of underscores. Consistency would be really nice. I am not saying we should rename everything (at least not until Python 3 =), but at least we can make sure new stuff that is not preexisting can use a consistent naming scheme. And as for it being contentious, I say Guido can pronounce on this. We are all grown-ups and can learn to name things in a certain way to give our memories an easier time. =) Same for me. Most time I can remember the name but stuck with capping of the word. And one of the advantages of Java std lib is that naming is consistent. I hope new stuff will follow only one naming style. And now we should (or one person :-) should) decide which one. And that's the way to go for new stuff in std lib. And it states as an example for external modules. As an example we can check if ElementTree matches this. g For Python 3 it's possible to switch to this consistent style. For a new and better world. bye by Wolfgang ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications, function/method style
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 and variables in lowerCapWords, constants optionally in ALL_CAPS. Abbrevs avoided, acronyms have all letters capitalized, eg: SimpleHTTPServer.) The conventions are nearly universally followed, and as a result in java I always know how to spell things. I never have to remember whether it's myDict.hasKey() and myDict.popitem() or myDict.has_key() and myDict.popItem(). Haskell goes too far -- they REQUIRE a certain convention as part of the language... this prevents breaking the rules on purpose (eg: wrapping a library from another language, or using an object with attributes to represent an XML node with child nodes). I agree completely with this. I might remember the name of a method, but I don't always remember the capping and the possible use of underscores. Consistency would be really nice. I am not saying we should rename everything (at least not until Python 3 =), but at least we can make sure new stuff that is not preexisting can use a consistent naming scheme. And as for it being contentious, I say Guido can pronounce on this. We are all grown-ups and can learn to name things in a certain way to give our memories an easier time. =) Same for me. Most time I can remember the name but stuck with capping of the word. And one of the advantages of Java std lib is that naming is consistent. I hope new stuff will follow only one naming style. And now we should (or one person :-) should) decide which one. And that's the way to go for new stuff in std lib. And it states as an example for external modules. As an example we can check if ElementTree matches this. g For Python 3 it's possible to switch to this consistent style. For a new and better world. bye by Wolfgang ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 8 updates/clarifications, function/method style
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), to retain backwards compatibility. Method Names and Instance Variables The story is largely the same as with functions: in general, use lowercase with words separated by underscores as necessary to improve readability. - We need a clear style for function and method names now std lib uses foo_bar sometimes foobar and sometimes fooBar. The use of lowercase with underscores is the default so the python std lib should use it in all modules. - Python 3000 std lib Or should we switch to camelCase with lowercase first letter ? As most other Languages prefer this (Java, C#, C++, ...) bye by Wolfgang ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications, function/method style
[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. wink -- Michael Hoffman [EMAIL PROTECTED] European Bioinformatics Institute ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications, function/method style
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. wink Or BEGIN, END style. :-) bye by Wolfgang ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications, function/method style
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 the conversation that preceded putting that into PEP 8, and the impetus for that particular decision was input from non-native English speakers (particularly those not coming from a European alphabet) that it was far easier to read with underscore separation rather than capWords. -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications, function/method style
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, methods, and variables! Guido writes: 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 and variables in lowerCapWords, constants optionally in ALL_CAPS. Abbrevs avoided, acronyms have all letters capitalized, eg: SimpleHTTPServer.) The conventions are nearly universally followed, and as a result in java I always know how to spell things. I never have to remember whether it's myDict.hasKey() and myDict.popitem() or myDict.has_key() and myDict.popItem(). Haskell goes too far -- they REQUIRE a certain convention as part of the language... this prevents breaking the rules on purpose (eg: wrapping a library from another language, or using an object with attributes to represent an XML node with child nodes). Of course, a really good IDE might make this irrelevent by popping up the correct option as I type... but the IDEs I use for Python don't even know the types of my variables, so they don't do this for me. Anyhow... I don't think we can change it now, but I _do_ believe that the lack of such conventions is a bit distracting. (Not enough to make me prefer Java, of course!) -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications, function/method style
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 to always use foo_bar because that's what PEP 8 says. I believe recall the conversation that preceded putting that into PEP 8, and the impetus for that particular decision was input from non-native English speakers (particularly those not coming from a European alphabet) that it was far easier to read with underscore separation rather than capWords. Correct, which is one reason I feel strongly that we should keep the current recommendation of lower_case_words. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications, function/method style
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 is that the PEP should keep its current recommendation of lower_case_words. It allows for the other styles under the be internally consistent guideline. My current rewrite (to be checked in soon), has this also to say: mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility. It could be argued that this guideline should be relaxed to give lower_case_words and mixedCase equal footing. I'd disagree, but will make that change to the PEP if there's strong consensus in favor of taking that position. I want to be adamant about module, package and class names though: module/package names should be short all-lowercase without underscores; class names should be CapWords. I'd like to fix this for StringIO.py, UserDict.py etc. Absolutely. The use of lowercase with underscores is the default so the python std lib should use it in all modules. Too late. I don't think the diversity is all that distracting. I'd be much more concerned about spelling MethodNames (as unfortunately the Google style guide requires). That's right out. :) -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 updates/clarifications, function/method style
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 package. Hurray! Now I can go back to using capWords for functions, methods, and variables! Guido writes: 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 and variables in lowerCapWords, constants optionally in ALL_CAPS. Abbrevs avoided, acronyms have all letters capitalized, eg: SimpleHTTPServer.) The conventions are nearly universally followed, and as a result in java I always know how to spell things. I never have to remember whether it's myDict.hasKey() and myDict.popitem() or myDict.has_key() and myDict.popItem(). Haskell goes too far -- they REQUIRE a certain convention as part of the language... this prevents breaking the rules on purpose (eg: wrapping a library from another language, or using an object with attributes to represent an XML node with child nodes). I agree completely with this. I might remember the name of a method, but I don't always remember the capping and the possible use of underscores. Consistency would be really nice. I am not saying we should rename everything (at least not until Python 3 =), but at least we can make sure new stuff that is not preexisting can use a consistent naming scheme. And as for it being contentious, I say Guido can pronounce on this. We are all grown-ups and can learn to name things in a certain way to give our memories an easier time. =) -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
