Re: Naming conventions for functions and methods
pyt...@bdurham.com writes: > Looking for your opinions on how you name your functions and > methods. Example: I have a function that hashes a file. I could > name this function hash_file() or file_hash(). I'd prefer just ‘hash’. The function name can be considered an action verb, with its arguments as the objects acted upon. -- \ “Nothing worth saying is inoffensive to everyone. Nothing worth | `\saying will fail to make you enemies. And nothing worth saying | _o__)will not produce a confrontation.” —Johann Hari, 2011 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Naming conventions for functions and methods
On 8 July 2014 15:59, wrote: > > Looking for your opinions on how you name your functions and methods. > Example: I have a function that hashes a file. I could name this function > hash_file() or file_hash(). The 1st naming convention sounds more natural, > the 2nd naming convention allows one to group related functions together by > the object being acted on. PEP-8 doesn't appear to offer guidance in this > area. Thoughts? Malcolm If you want to group related functions together, I would suggest putting them in a module, e.g. 'fileutils'. I'd still go for hashfile for the function name though. -- Arnaud -- https://mail.python.org/mailman/listinfo/python-list
Naming conventions for functions and methods
Looking for your opinions on how you name your functions and methods. Example: I have a function that hashes a file. I could name this function hash_file() or file_hash(). The 1st naming convention sounds more natural, the 2nd naming convention allows one to group related functions together by the object being acted on. PEP-8 doesn't appear to offer guidance in this area. Thoughts? Malcolm -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal about naming conventions around packaging
On 5/30/12 6:59 PM, Benoît Bryon wrote: Hi, Hi Benoit you should post this to the distutils SIG Thank you Here is a proposal about naming conventions around packaging. Main question is: would you accept it as a PEP? Preliminary notes (not part of the proposal) Before I start, here are some preliminary notes about the context... * Situation * * first posted to distutils-sig list: http://mail.python.org/pipermail/distutils-sig/2012-May/018551.html * then opened a ticket on CPython issue tracker: http://bugs.python.org/issue14899 * started to work in a fork... https://bitbucket.org/benoitbryon/cpython/src/doc-package-names/Doc/packaging/packagenames.rst * ... but this looks like a PEP. So, let's follow PEP 1 and post a proposal here. *** What follows is a draft *** * First of all, I promise I did my best ;) * I guess most points already have been discussed here or elsewhere. But since I couldn't find an official reference (i.e. a refused PEP), I believe consensus is possible. * I splitted proposals in small sections, so that people can discuss or refuse some items while accepting others. If you see something that is not atomic, please propose a split. * I tried to relate facts. But I feel like a newbie about some points, so, if you see something wrong or incomplete, please send information and/or sources. * I tried to propose actions and take existing projects into account. In my humble opinion, motivations and proposals below seem reasonable enough. That's why I am posting here to get feedback from the community. * Finally, I am not a native english speaker... feel free to improve vocabulary, grammar and so on :) That said, let's go... .. note:: You can also get the following proposal online at https://bitbucket.org/benoitbryon/cpython/src/doc-package-names/Doc/packaging/packagenames.rst Thanks to Martin Aspeli for his article. Thanks to early reviewers: Alexis Métaireau, Éric Bréhault, Jean-Philippe Camguilhem and Mathieu Leplâtre. Regards, Benoit ### Names in packaging: conventions and recipes ### This document deals with: * names of Python projects, * names of distributions in projects, * names of Python packages or modules being distributed, * namespace packages. It provides conventions and recipes for distribution authors. Main use case is: * as a developer, I want to create a project in order to distribute a package. So I have to choose names. Which names are "good"? * `The Zen of Python`_ says: In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. * So I need clear and official (i.e. obvious) guidelines or conventions that I can follow. * Here are conventions, guidelines and recipes. Guidelines for existing projects are also given. *** Terminology *** First of all, let's make sure there is no confusion... Distribution name Distribution name is used by packaging utilities: * in :doc:`setup script`, it is the value passed as ``name`` to ``packaging.core.setup()`` * it appears on `PyPI`_ if the package is registered on it * it can be used in `pip` requirements files * it can be used in `buildout` configuration files. Distribution term is introduced in :doc:`packaging docs`. Egg name It is the same concept as distribution name. Technically, the egg is not the distribution. But they use the same name: it is declared as ``packaging.core.setup()`` name argument. "Egg" term is the legacy counterpart to "distribution". It was used by distutils and setuptools. It becomes deprecated with the new packaging module. This document focuses on distributions, not eggs. Package and module names Package and module names are used in Python code. It is the string used in :ref:`import statements`. Remember that, from a file system perspective, packages are directories and modules are files. :ref:`Python packaging allows distributions to distribute several packages and/or modules`. Project name Usually the name of the repository or folder in which distribution authors put their code. It generally is the directory name of the "distribution root", as defined in :ref:`packaging-term`. Namespace packages It is common practice to use namespaces in package names. `PEP 420`_ brings this concept to core Python. When PEP 420 will be accepted, Python officially supports namespace packages. As an example, consider `django-debug-toolbar`_: * ``django-debug-toolbar`` is the distribution name. `It is declared in setup.py file <https://github.com/django-debug-toolba
Proposal about naming conventions around packaging
Hi, Here is a proposal about naming conventions around packaging. Main question is: would you accept it as a PEP? Preliminary notes (not part of the proposal) Before I start, here are some preliminary notes about the context... * Situation * * first posted to distutils-sig list: http://mail.python.org/pipermail/distutils-sig/2012-May/018551.html * then opened a ticket on CPython issue tracker: http://bugs.python.org/issue14899 * started to work in a fork... https://bitbucket.org/benoitbryon/cpython/src/doc-package-names/Doc/packaging/packagenames.rst * ... but this looks like a PEP. So, let's follow PEP 1 and post a proposal here. *** What follows is a draft *** * First of all, I promise I did my best ;) * I guess most points already have been discussed here or elsewhere. But since I couldn't find an official reference (i.e. a refused PEP), I believe consensus is possible. * I splitted proposals in small sections, so that people can discuss or refuse some items while accepting others. If you see something that is not atomic, please propose a split. * I tried to relate facts. But I feel like a newbie about some points, so, if you see something wrong or incomplete, please send information and/or sources. * I tried to propose actions and take existing projects into account. In my humble opinion, motivations and proposals below seem reasonable enough. That's why I am posting here to get feedback from the community. * Finally, I am not a native english speaker... feel free to improve vocabulary, grammar and so on :) That said, let's go... .. note:: You can also get the following proposal online at https://bitbucket.org/benoitbryon/cpython/src/doc-package-names/Doc/packaging/packagenames.rst Thanks to Martin Aspeli for his article. Thanks to early reviewers: Alexis Métaireau, Éric Bréhault, Jean-Philippe Camguilhem and Mathieu Leplâtre. Regards, Benoit ### Names in packaging: conventions and recipes ### This document deals with: * names of Python projects, * names of distributions in projects, * names of Python packages or modules being distributed, * namespace packages. It provides conventions and recipes for distribution authors. Main use case is: * as a developer, I want to create a project in order to distribute a package. So I have to choose names. Which names are "good"? * `The Zen of Python`_ says: In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. * So I need clear and official (i.e. obvious) guidelines or conventions that I can follow. * Here are conventions, guidelines and recipes. Guidelines for existing projects are also given. *** Terminology *** First of all, let's make sure there is no confusion... Distribution name Distribution name is used by packaging utilities: * in :doc:`setup script`, it is the value passed as ``name`` to ``packaging.core.setup()`` * it appears on `PyPI`_ if the package is registered on it * it can be used in `pip` requirements files * it can be used in `buildout` configuration files. Distribution term is introduced in :doc:`packaging docs`. Egg name It is the same concept as distribution name. Technically, the egg is not the distribution. But they use the same name: it is declared as ``packaging.core.setup()`` name argument. "Egg" term is the legacy counterpart to "distribution". It was used by distutils and setuptools. It becomes deprecated with the new packaging module. This document focuses on distributions, not eggs. Package and module names Package and module names are used in Python code. It is the string used in :ref:`import statements`. Remember that, from a file system perspective, packages are directories and modules are files. :ref:`Python packaging allows distributions to distribute several packages and/or modules`. Project name Usually the name of the repository or folder in which distribution authors put their code. It generally is the directory name of the "distribution root", as defined in :ref:`packaging-term`. Namespace packages It is common practice to use namespaces in package names. `PEP 420`_ brings this concept to core Python. When PEP 420 will be accepted, Python officially supports namespace packages. As an example, consider `django-debug-toolbar`_: * ``django-debug-toolbar`` is the distribution name. `It is declared in setup.py file <https://github.com/django-debug-toolbar/django-debug-toolbar/blob/599d76e41c5728c0e342d55250690b2694bd2aad/setup.py#L4>`_. * ``debug_toolbar`` is the package name. It
Re: PEP for module naming conventions
I have found this approach problematic if you have packages separately developed and maintained in different directory trees, resulting in more than one PYTHONPATH entry with the same root metapackage name. What happens is that only the first entry in the PYTHONPATH containing the metapackage name is looked in for package/module resolution. Do you have any suggestions for handling this kind of packaging? On Thu, Mar 17, 2011 at 12:17 PM, eryksun () wrote: > On Friday, March 11, 2011 4:52:57 PM UTC-5, Tim Johnson wrote: >> I need to be better informed on naming conventions for modules. For >> instance, I need to create a new module and I want to make sure that >> the module name will not conflict with any future or current python >> system module names. > > Do you mean package names? Within a package you can use relative imports to > avoid conflicts. You could put all of your packages in a metapackage > namespace with a unique name -- a company/group name or personal/family name, > an uncommon English word, or something from another language. > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP for module naming conventions
On Friday, March 11, 2011 4:52:57 PM UTC-5, Tim Johnson wrote: > I need to be better informed on naming conventions for modules. For > instance, I need to create a new module and I want to make sure that > the module name will not conflict with any future or current python > system module names. Do you mean package names? Within a package you can use relative imports to avoid conflicts. You could put all of your packages in a metapackage namespace with a unique name -- a company/group name or personal/family name, an uncommon English word, or something from another language. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP for module naming conventions
Tim Johnson wrote: > I need to be better informed on naming conventions for modules. For > instance, I need to create a new module and I want to make sure that > the module name will not conflict with any future or current python > system module names. COBOL in its golden years had a practice that reserved words were almost never hyphenated -- the few that were could be counted on the fingers of perhaps four hands and were mostly required paragraph names that were always used and hard to forget. It might turn out well to specify that system module names will never contain more than, say, one underscore. That way, nice descriptive application module names like 'analyzer_tool_utils' and such would always be safe to use. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP for module naming conventions
* Ben Finney [110313 17:15]: > Tim Johnson writes: > > > I need to be better informed on naming conventions for modules. For > > instance, I need to create a new module and I want to make sure that > > the module name will not conflict with any future or current python > > system module names. > > You'll never be able to make sure of that, and you would be needlessly > eliminating a whole lot of potentially useful names for your modules. > > Have you read and understood PEP 328, which introduces the distinction > between relative and absolute imports? It's designed to avoid the > problem your describing http://www.python.org/dev/peps/pep-0328/>. Have read, don't fully understand, but it sounds like the dust hasn't settled yet. It will sink in. thanks tim > > There may be a PEP for this, if so, a URL to such a PEP would suffice > > for my inquiry. Also, if there is an index of PEPs, a link to such > > would also be appreciated. > > PEP 0 is the index of all PEPs > http://www.python.org/dev/peps/pep-/>. > > -- > \ “Pinky, are you pondering what I'm pondering?” “I think so, | > `\ Brain, but if we have nothing to fear but fear itself, why does | > _o__) Elanore Roosevelt wear that spooky mask?” —_Pinky and The Brain_ | > Ben Finney > -- > http://mail.python.org/mailman/listinfo/python-list -- Tim tim at johnsons-web.com or akwebsoft.com http://www.akwebsoft.com -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP for module naming conventions
Tim Johnson writes: > I need to be better informed on naming conventions for modules. For > instance, I need to create a new module and I want to make sure that > the module name will not conflict with any future or current python > system module names. You'll never be able to make sure of that, and you would be needlessly eliminating a whole lot of potentially useful names for your modules. Have you read and understood PEP 328, which introduces the distinction between relative and absolute imports? It's designed to avoid the problem your describing http://www.python.org/dev/peps/pep-0328/>. > There may be a PEP for this, if so, a URL to such a PEP would suffice > for my inquiry. Also, if there is an index of PEPs, a link to such > would also be appreciated. PEP 0 is the index of all PEPs http://www.python.org/dev/peps/pep-/>. -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\ Brain, but if we have nothing to fear but fear itself, why does | _o__) Elanore Roosevelt wear that spooky mask?” —_Pinky and The Brain_ | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP for module naming conventions
* David Marek [110311 13:20]: > Hi, > > Have you read PEP 8? http://python.org/dev/peps/pep-0008/ > I don't think it's possible to be sure that the name of your module > won't conflict with system module name (if you'll follow conventions). > > You can find the list of all PEPs at http://python.org/dev/peps/ Thank you for the links David. > -- > David Marek > dav...@atrey.karlin.mff.cuni.cz > http://davidmarek.cz And interesting web site. The future is with us. > > On Fri, Mar 11, 2011 at 10:52 PM, Tim Johnson wrote: > > I need to be better informed on naming conventions for modules. For > > instance, I need to create a new module and I want to make sure that > > the module name will not conflict with any future or current python > > system module names. > > > > There may be a PEP for this, if so, a URL to such a PEP would > > suffice for my inquiry. Also, if there is an index of PEPs, a link > > to such would also be appreciated. > > > > thanks > > -- > > Tim > > tim at johnsons-web.com or akwebsoft.com > > http://www.akwebsoft.com > > -- > > http://mail.python.org/mailman/listinfo/python-list > > -- Tim tim at johnsons-web.com or akwebsoft.com http://www.akwebsoft.com -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP for module naming conventions
Hi, Have you read PEP 8? http://python.org/dev/peps/pep-0008/ I don't think it's possible to be sure that the name of your module won't conflict with system module name (if you'll follow conventions). You can find the list of all PEPs at http://python.org/dev/peps/ -- David Marek dav...@atrey.karlin.mff.cuni.cz http://davidmarek.cz On Fri, Mar 11, 2011 at 10:52 PM, Tim Johnson wrote: > I need to be better informed on naming conventions for modules. For > instance, I need to create a new module and I want to make sure that > the module name will not conflict with any future or current python > system module names. > > There may be a PEP for this, if so, a URL to such a PEP would > suffice for my inquiry. Also, if there is an index of PEPs, a link > to such would also be appreciated. > > thanks > -- > Tim > tim at johnsons-web.com or akwebsoft.com > http://www.akwebsoft.com > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
PEP for module naming conventions
I need to be better informed on naming conventions for modules. For instance, I need to create a new module and I want to make sure that the module name will not conflict with any future or current python system module names. There may be a PEP for this, if so, a URL to such a PEP would suffice for my inquiry. Also, if there is an index of PEPs, a link to such would also be appreciated. thanks -- Tim tim at johnsons-web.com or akwebsoft.com http://www.akwebsoft.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
In article <4c3a8087$0$28662$c3e8...@news.astraweb.com>, Steven D'Aprano wrote: > >For some reason, when I answer the phone and say "Hello, Steven >speaking?" I often get called Peter. That's the Peter Principle in action. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "Normal is what cuts off your sixth finger and your tail..." --Siobhan -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
On 2010-07-12, Steven D'Aprano wrote: > On Sun, 11 Jul 2010 01:30:36 -0700, rantingrick wrote: > >> On Jul 11, 3:03??am, "G??nther Dietrich" wrote: >> >>> So, it is not a disadvantage that the functions you listed above are >>> named in this way. In the contrary, it is an advantage, as it keeps >>> newcomers from using stupid variable names. >> >> "int" for an Integer is stupid? >> "list" for a List is stupid? >> "str" for a String is stupid? >> >> What am i missing? > > If you're going to use generic names, why type three or four letters when > one will do? > > i, j, k, m, n, p, q for ints. > L, a, b, x for lists > s, t, a, b for strings. > > If you don't want to use generic names, then int, list, str are useless > because they don't mean anything. You need something like: > > count_of_widgets > list_of_widgets > description def map(function, list): # etc. It's a slight annoyance, nothing more. In the data I deal with, I get annoyed at needing to write student_id instead of id, but it's not a huge issue. The big consolation is that Python really doesn't care if I happen to shadow a builtin name that I've never heard of. I forget, and use id as a variable all the time, and nothing bad happens to me, because I don't need the builtin function. To see a really odd example of a similar name clash, create a tab separated values file with a header line starting with ID (I get lots of them in my work), and then open it with Excel (I don't know which version has the most bizarre error message). -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
rantingrick wrote: On Jul 11, 3:03 am, "Günther Dietrich" wrote: So, it is not a disadvantage that the functions you listed above are named in this way. In the contrary, it is an advantage, as it keeps newcomers from using stupid variable names. "int" for an Integer is stupid? "list" for a List is stupid? "str" for a String is stupid? What am i missing? def func154(): int32 = 24 list18 = [int32, 14] str14 = "" for int89 in list18: if int89 == int32 or int89 == 88: str14 = "I am missing everything" if str14: print str14 >>> func154() >>> "I am missing everything" JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
On 12Jul2010 02:43, Steven D'Aprano wrote: | On Mon, 12 Jul 2010 02:40:07 +, Steven D'Aprano wrote: | > On Mon, 12 Jul 2010 01:31:14 +0100, Mark Lawrence wrote: | >> Well said Steven, or is it Stephen, or Stephan, or Stefen, or what? | > | > For some reason, when I answer the phone and say "Hello, Steven | > speaking?" I often get called Peter. | | Er, without the question mark. Ah, so you get differing results when you use the question mark? Phonetic punctuation; Victor Borge would be proud. -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ A lot of people don't know the difference between a violin and a viola, so I'll tell you. A viola burns longer. - Victor Borge -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
On 7/11/2010 3:26 AM, rantingrick wrote: Another source of asininity seems to be the naming conventions of the Python language proper! True/False start with an upper case and i applaud this. However str, list, tuple, int, float --need i go on...?-- start with lowercase. This is an anomaly, known to all long-time Pythoneers, due the the history of Python. Before 2.2 and unification of types and classes as new-style classes, those were all type constructor *functions*, not class names. The idea of breaking most every serious Python program on the planet by upper-casing them has been considered and so far rejected. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
On Mon, 12 Jul 2010 02:40:07 +, Steven D'Aprano wrote: > On Mon, 12 Jul 2010 01:31:14 +0100, Mark Lawrence wrote: > >> Well said Steven, or is it Stephen, or Stephan, or Stefen, or what? > > For some reason, when I answer the phone and say "Hello, Steven > speaking?" I often get called Peter. Er, without the question mark. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
On Mon, 12 Jul 2010 01:31:14 +0100, Mark Lawrence wrote: > Well said Steven, or is it Stephen, or Stephan, or Stefen, or what? For some reason, when I answer the phone and say "Hello, Steven speaking?" I often get called Peter. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
On 12/07/2010 01:06, Steven D'Aprano wrote:
On Sun, 11 Jul 2010 00:26:36 -0700, rantingrick wrote:
Another source of asininity seems to be the naming conventions of the
Python language proper! True/False start with an upper case and i
applaud this. However str, list, tuple, int, float --need i go on...?--
start with lowercase.
Q: Well what the hell is your problem Rick. Who cares right?
WRONG, I tell you what my problem is. Now i cannot "wisely" use
variables like...
str="this is a string"
list = [1,2,3]
def make_random_objs(range=10)
def show_message(str)
int = 12
Yes. So what? You can't wisely use variables like:
True = "rantingrick is an obnoxious loudmouth"
+1 QOTW
None = "the problem he is describing"
Nor can you wisely use variables like:
len = len("something")
chr = chr(48)
[...]
Just thoughts.
But not deep thoughts.
Well said Steven, or is it Stephen, or Stephan, or Stefen, or what?
Kindest regards.
Mark Lawrence.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
On Sun, 11 Jul 2010 00:26:36 -0700, rantingrick wrote:
> Another source of asininity seems to be the naming conventions of the
> Python language proper! True/False start with an upper case and i
> applaud this. However str, list, tuple, int, float --need i go on...?--
> start with lowercase.
>
> Q: Well what the hell is your problem Rick. Who cares right?
>
> WRONG, I tell you what my problem is. Now i cannot "wisely" use
> variables like...
>
> str="this is a string"
> list = [1,2,3]
> def make_random_objs(range=10)
> def show_message(str)
> int = 12
Yes. So what? You can't wisely use variables like:
True = "rantingrick is an obnoxious loudmouth"
None = "the problem he is describing"
Nor can you wisely use variables like:
len = len("something")
chr = chr(48)
[...]
> Just thoughts.
But not deep thoughts.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
On Sun, 11 Jul 2010 01:30:36 -0700, rantingrick wrote: > On Jul 11, 3:03 am, "Günther Dietrich" wrote: > >> So, it is not a disadvantage that the functions you listed above are >> named in this way. In the contrary, it is an advantage, as it keeps >> newcomers from using stupid variable names. > > "int" for an Integer is stupid? > "list" for a List is stupid? > "str" for a String is stupid? > > What am i missing? If you're going to use generic names, why type three or four letters when one will do? i, j, k, m, n, p, q for ints. L, a, b, x for lists s, t, a, b for strings. If you don't want to use generic names, then int, list, str are useless because they don't mean anything. You need something like: count_of_widgets list_of_widgets description -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
On Jul 11, 12:23 pm, MRAB wrote: > If you're so unhappy with Python, why don't you create your own > language. I suggest the name "Rantthon". Ah yes, then i can finally assume my worthy title of the "Ranting Dictator For Life"! ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
rantingrick wrote: Another source of asininity seems to be the naming conventions of the Python language proper! True/False start with an upper case and i applaud this. However str, list, tuple, int, float --need i go on...?-- start with lowercase. Q: Well what the hell is your problem Rick. Who cares right? WRONG, I tell you what my problem is. Now i cannot "wisely" use variables like... str="this is a string" list = [1,2,3] def make_random_objs(range=10) def show_message(str) int = 12 If we would have adopted proper naming conventions from dios numero uno all this nonsense would be rectified! Str, Float, List, Range, etc, etc. You think Python 3000 was a hump to climb over just wait for Python 4000. Just thoughts. If you're so unhappy with Python, why don't you create your own language. I suggest the name "Rantthon". -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
Andreas Waldenburger wrote: > > Having capitalized boolean values ... that is a bit odd, but as long as > children are starving in Africa, this isn't very high on my gripe-list. > +1 -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
On Sun, 11 Jul 2010 15:46:40 +0200 News123 wrote: > Andre Alexander Bell wrote: > > On 07/11/2010 10:30 AM, rantingrick wrote: > > >>> So, it is not a disadvantage that the functions you listed above > >>> are named in this way. In the contrary, it is an advantage, as it > >>> keeps newcomers from using stupid variable names. > >> "int" for an Integer is stupid? > >> "list" for a List is stupid? > >> "str" for a String is stupid? > >> > >> What am i missing? > > > > [snip] > > hm, well sometimes I do write generic functions, that do something > with a list or a string or an int. > > [snip] > > I must admit, that I have still problems > to not use the variables range or id > There are several approaches: - Use range_, id_, and so on. I think this is the proposed convention. Slightly ugly, though. - Use abbreviations, or misspellings like lst, Set, klass, ... Less ugly, but can get weird. - Prepend 'a' to a type name: alist, aset, astr. Similar weirdness potential as above, but more consistent in terms of style. I sometimes take this to the extreme and prepend 'some_'. So really, this is a non issue, at least for me. Having capitalized boolean values ... that is a bit odd, but as long as children are starving in Africa, this isn't very high on my gripe-list. /W -- INVALID? DE! -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
Andre Alexander Bell wrote: > On 07/11/2010 10:30 AM, rantingrick wrote: >>> So, it is not a disadvantage that the functions you listed above are >>> named in this way. In the contrary, it is an advantage, as it keeps >>> newcomers from using stupid variable names. >> "int" for an Integer is stupid? >> "list" for a List is stupid? >> "str" for a String is stupid? >> >> What am i missing? > > You are missing (from PEP 8): > > --- 8< --- 8< --- > Class Names > > Almost without exception, class names use the CapWords convention. > Classes for internal use have a leading underscore in addition. > > --- 8< --- 8< --- > > You may want to think of list, int, str, object, ... as classes that > don't follow this advice with their class name. > > But besides that, shouldn't a variable name reflect it's purpose instead > of it's type? E.g. hm, well sometimes I do write generic functions, that do something with a list or a string or an int. However a simple way around this is to use following naming style. to replace def process_list(list): dostuff_with(list) with def process_list(alist): dostuff_with(alist) or with def process_list(a_list): dostuff_with(a_list) I must admit, that I have still problems to not use the variables range or id -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
On Sun, 11 Jul 2010 00:26:36 -0700 (PDT) rantingrick wrote: > Another source of asininity seems to be the naming conventions of the > Python language proper! True/False start with an upper case and i > applaud this. However str, list, tuple, int, float --need i go > on...?-- start with lowercase. Achtually, these are type names with their own constructor. The name of the type of True and False is bool and, bool() returns a bool-object. regards, Marek -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
On 07/11/2010 10:30 AM, rantingrick wrote: > On Jul 11, 3:03 am, "Günther Dietrich" > wrote: > >> So, it is not a disadvantage that the functions you listed above are >> named in this way. In the contrary, it is an advantage, as it keeps >> newcomers from using stupid variable names. > > "int" for an Integer is stupid? > "list" for a List is stupid? > "str" for a String is stupid? > > What am i missing? You are missing (from PEP 8): --- 8< --- 8< --- Class Names Almost without exception, class names use the CapWords convention. Classes for internal use have a leading underscore in addition. --- 8< --- 8< --- You may want to think of list, int, str, object, ... as classes that don't follow this advice with their class name. But besides that, shouldn't a variable name reflect it's purpose instead of it's type? E.g. name = 'rantingrick' counter = 1 ... as compared to str = 'rantingrick' int = 1? Regards Andre -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
On Jul 11, 3:03 am, "Günther Dietrich" wrote: > So, it is not a disadvantage that the functions you listed above are > named in this way. In the contrary, it is an advantage, as it keeps > newcomers from using stupid variable names. "int" for an Integer is stupid? "list" for a List is stupid? "str" for a String is stupid? What am i missing? -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
rantingrick wrote: >Another source of asininity seems to be the naming conventions of the >Python language proper! True/False start with an upper case and i >applaud this. However str, list, tuple, int, float --need i go >on...?-- start with lowercase. > >Q: Well what the hell is your problem Rick. Who cares right? > >WRONG, I tell you what my problem is. Now i cannot "wisely" use >variables like... > >str="this is a string" >list = [1,2,3] >def make_random_objs(range=10) >def show_message(str) >int = 12 Someone who wants to write readable and maintainable code would (practically) never want to use variables named in this way. Why? Because these names don't tell anything about the purpose of the variables. So, it is not a disadvantage that the functions you listed above are named in this way. In the contrary, it is an advantage, as it keeps newcomers from using stupid variable names. >If we would have adopted proper naming conventions from dios numero >uno all this nonsense would be rectified! Str, Float, List, Range, >etc, etc. You think Python 3000 was a hump to climb over just wait for >Python 4000. Additionally to what I mention above, there is PEP 0008. Read it, you can learn from it. What you listed above, are functions, and their names comply completely with PEP 0008. Regards, Günther PS: Even though I suspect that you are simply an agitator rsp. troll (based on what you posted in this group so far), and normally I refuse to feed trolls, I make an exception in this case, so newcomers ar not mislead by your half-baked ideas. -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming Conventions, Where's the Convention Waldo?
* rantingrick, on 11.07.2010 09:26: Another source of asininity seems to be the naming conventions of the Python language proper! True/False start with an upper case and i applaud this. However str, list, tuple, int, float --need i go on...?-- start with lowercase. Q: Well what the hell is your problem Rick. Who cares right? WRONG, I tell you what my problem is. Now i cannot "wisely" use variables like... str="this is a string" list = [1,2,3] def make_random_objs(range=10) def show_message(str) int = 12 If we would have adopted proper naming conventions from dios numero uno all this nonsense would be rectified! Str, Float, List, Range, etc, etc. You think Python 3000 was a hump to climb over just wait for Python 4000. Just thoughts. Just do Str = str List = list Float = float and so on in module "myBasicTypes", and import that. :-) Cheers & hth., - Alf -- blog at http://alfps.wordpress.com> -- http://mail.python.org/mailman/listinfo/python-list
Naming Conventions, Where's the Convention Waldo?
Another source of asininity seems to be the naming conventions of the Python language proper! True/False start with an upper case and i applaud this. However str, list, tuple, int, float --need i go on...?-- start with lowercase. Q: Well what the hell is your problem Rick. Who cares right? WRONG, I tell you what my problem is. Now i cannot "wisely" use variables like... str="this is a string" list = [1,2,3] def make_random_objs(range=10) def show_message(str) int = 12 If we would have adopted proper naming conventions from dios numero uno all this nonsense would be rectified! Str, Float, List, Range, etc, etc. You think Python 3000 was a hump to climb over just wait for Python 4000. Just thoughts. -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint naming conventions?
R. David Murray wrote: Well, I for one looked at that long pylint output when I first tried it, and switched to another tool :) (pyflakes...but I don't think it does PEP 8) :-) Ok, so I'm not the only one who thinks the output is rather lengthy. I've since dug into the docs and searched on the web and found that --reports=n on the command line will truncate the various tables output at the end. Esmail -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint naming conventions?
Esmail wrote: > Ben Finney wrote: > > My understanding of Esmail's original message was that, like many of us > > on first running ‘pylint’ against an existing code base, the output is > > astonishingly verbose and tedious to read. By the above I presume he's > > being a good forum member and trying to find a minimal example that > > shows the problem clearly :-) > > Yes, that is my intention .. because the code I was checking was rather > long, combined with the long pylint output it would make for a rather > big posting. > > I'm going to go back and re-read PEP 8 and see if I perhaps don't > recall the right guidelines since no one else here seems to have had > the same observation. Well, I for one looked at that long pylint output when I first tried it, and switched to another tool :) (pyflakes...but I don't think it does PEP 8) -- R. David Murray http://www.bitdance.com IT ConsultingSystem AdministrationPython Programming -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint naming conventions?
Ben Finney wrote: My understanding of Esmail's original message was that, like many of us on first running ‘pylint’ against an existing code base, the output is astonishingly verbose and tedious to read. By the above I presume he's being a good forum member and trying to find a minimal example that shows the problem clearly :-) Yes, that is my intention .. because the code I was checking was rather long, combined with the long pylint output it would make for a rather big posting. I'm going to go back and re-read PEP 8 and see if I perhaps don't recall the right guidelines since no one else here seems to have had the same observation. Esmail -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint naming conventions?
Hi David, David Stanek wrote: It is my understanding that it does check for PEP8 names. Even if it doesn't it is really easy to change. If you run 'pylint --generate-rcfile' (i think) it will output the configuration that it is using. You can then save this off and customize it. Thanks, I'll see if I can customize it this way. I looked at it once briefly. I'll try to come up with a nice short code example in the next few days to demonstrate what I think the problem is and post it, thanks for the suggestion. If you didn't have an example handy what prompted you to start this thread? :-) I have had number of examples, but they are rather long, so I think it will be better if I can provide a short example with the (rather lengthy pylint) output that shows the problem. I thought lots of people are using pylint and I would hear one way or the other about the name checks (ie people agreeing or telling me I'm way off :) .. in which case perhaps my recollection/reading of PEP 8 is not accurate. Esmail -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint naming conventions?
David Stanek writes: > On Sun, Jun 7, 2009 at 9:23 AM, Esmail wrote: > > I'll try to come up with a nice short code example in the next few > > days to demonstrate what I think the problem is and post it, thanks > > for the suggestion. > > If you didn't have an example handy what prompted you to start this > thread? My understanding of Esmail's original message was that, like many of us on first running ‘pylint’ against an existing code base, the output is astonishingly verbose and tedious to read. By the above I presume he's being a good forum member and trying to find a minimal example that shows the problem clearly :-) -- \“Kill myself? Killing myself is the last thing I'd ever do.” | `\—Homer, _The Simpsons_ | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint naming conventions?
On Sun, Jun 7, 2009 at 9:23 AM, Esmail wrote: > Ben Finney wrote: >> >> Esmail writes: >> >>> I am confused by pylint's naming conventions, I don't think the are in >>> tune with Python's style recommendations (PEP 8?) >>> >>> Anyone else think this? >> >> It's hard to know, without examples. Can you give some output of pylint >> that you think doesn't agree with PEP 8? > > Sure, I will next time I have a nice self-contained example. Perhaps not > that > many people are using pylint? I was expecting a bunch of messages either > contradicting my observation or agreeing with it :-) .. but perhaps this > indicates that there's no issue. It is my understanding that it does check for PEP8 names. Even if it doesn't it is really easy to change. If you run 'pylint --generate-rcfile' (i think) it will output the configuration that it is using. You can then save this off and customize it. > > I'll try to come up with a nice short code example in the next few days > to demonstrate what I think the problem is and post it, thanks for the > suggestion. If you didn't have an example handy what prompted you to start this thread? -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint naming conventions?
Ben Finney wrote: Esmail writes: I am confused by pylint's naming conventions, I don't think the are in tune with Python's style recommendations (PEP 8?) Anyone else think this? It's hard to know, without examples. Can you give some output of pylint that you think doesn't agree with PEP 8? Sure, I will next time I have a nice self-contained example. Perhaps not that many people are using pylint? I was expecting a bunch of messages either contradicting my observation or agreeing with it :-) .. but perhaps this indicates that there's no issue. I'll try to come up with a nice short code example in the next few days to demonstrate what I think the problem is and post it, thanks for the suggestion. Esmail -- http://mail.python.org/mailman/listinfo/python-list
Re: pylint naming conventions?
Esmail writes: > I am confused by pylint's naming conventions, I don't think the are in > tune with Python's style recommendations (PEP 8?) > > Anyone else think this? It's hard to know, without examples. Can you give some output of pylint that you think doesn't agree with PEP 8? -- \ “Are you thinking what I'm thinking, Pinky?” “Uh... yeah, | `\ Brain, but where are we going to find rubber pants our size?” | _o__) —_Pinky and The Brain_ | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
pylint naming conventions?
Hi, as someone who is still learning a lot about Python I am making use of all the tools that can help me, such as pyflakes, pychecker and pylint. I am confused by pylint's naming conventions, I don't think the are in tune with Python's style recommendations (PEP 8?) Anyone else think this? Is there an easy way to get this in compliance? Or lacking this just turn this off (I'd rather not turn it off if it's easy to get in tune with the standards). Or am I wrong about my assertion with regard to the naming conventions? Thanks, Esmail ps: if anyone else wants to toss in some other recommendations for useful tools feel free to do so! -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming conventions for regular variables
mk <[EMAIL PROTECTED]> writes: > 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." > > However, this PEP does not recommend any particular style for naming > regular (local) variables. Yes, it does: "Method Names and Instance Variables" applies. Any object that isn't a class is an "instance", to be named according to that section. > Personally I like "mixedCase" Nothing in PEP 8 allows mixedCase (except for the rare degenerate case where you're constrained to closely follow an existing naming convention). It's always TitleCase or lowercase, with or without underscores. > Naming both functions and variables using "lowercase with underscore > separator between words for readability" leads to confusing function > names with variable names - and distinguishing between variables and > function names just by looking at them would be nice. Functions are first-class objects in Python, and many non-function objects are callable. So, such an arbitrary distinction wouldn't be helpful. It's more sensible to distinguish by *usage*: is it being called or not? > Recommendations? Follow PEP 8, including the avoidance of mixedCase. -- \ “I went to a general store. They wouldn't let me buy anything | `\ specifically.” —Steven Wright | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Naming conventions for regular variables
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." However, this PEP does not recommend any particular style for naming regular (local) variables. Personally I like "mixedCase", however using both styles looks a bit weird: def some_function_name(someVariableName, anotherVar) Naming both functions and variables using "lowercase with underscore separator between words for readability" leads to confusing function names with variable names - and distinguishing between variables and function names just by looking at them would be nice. Recommendations? -- http://mail.python.org/mailman/listinfo/python-list
Re: Developing Techniques (and naming conventions)
Adekoba wrote: > On Feb 24, 1:06 pm, Christian Heimes <[EMAIL PROTECTED]> wrote: >> Adekoba wrote: >>> food.py >>> food/ >>> __init__.py >>> ham.py >>> cheese.py >>> where food.py is a script that uses the package food. Is it possible >>> for this to work in any way? Every time I try to run food.py, python >>> tries to import everything from the script instead of from the >>> package. How can I fix this? >> Move the code from food.py to food/__init__.py. You can't have a package >> and a module with the same name. >> >> Christian > > So it is not possible? > > I don't think moving food.py's code to __init__.py would work out to > well, because then how would I run the script? You run food/__init__.py with the following statement: import food regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Developing Techniques (and naming conventions)
On Feb 24, 3:21 pm, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED] nomine.org> wrote: > -On [20080224 20:01], Adekoba ([EMAIL PROTECTED]) wrote: > > >I don't think moving food.py's code to __init__.py would work out to > >well, because then how would I run the script? > > import food > > Which in turn has something like this in food/__init__.py: > > from food.cheese import gouda > from food.ham import parma > > __all__ = ['gouda', 'parma'] > > and in turn in your script you can now use food.gouda and food.parma. > > Unless I totally misunderstood what you are trying to achieve. > > -- > Jeroen Ruigrok van der Werven / asmodai > イェルーン ラウフロック ヴァン デル ウェルヴェンhttp://www.in-nomine.org/|http://www.rangaku.org/ > We have met the enemy and they are ours... I was just curious if I could get a script name to be the same name as the package directory, but apparently it is not possible. Instead I think I am going to do something like: setup.py food/ __init__.py ham.py cheese.py scripts/ food and just set my PYTHONPATH to the parent directory. I have never done a full scale project before in python, but I think this is probably on track with what most people would do. -- http://mail.python.org/mailman/listinfo/python-list
Re: Developing Techniques (and naming conventions)
-On [20080224 20:01], Adekoba ([EMAIL PROTECTED]) wrote: >I don't think moving food.py's code to __init__.py would work out to >well, because then how would I run the script? import food Which in turn has something like this in food/__init__.py: from food.cheese import gouda from food.ham import parma __all__ = ['gouda', 'parma'] and in turn in your script you can now use food.gouda and food.parma. Unless I totally misunderstood what you are trying to achieve. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ We have met the enemy and they are ours... -- http://mail.python.org/mailman/listinfo/python-list
Re: Developing Techniques (and naming conventions)
On Feb 24, 1:06 pm, Christian Heimes <[EMAIL PROTECTED]> wrote: > Adekoba wrote: > > food.py > > food/ > > __init__.py > > ham.py > > cheese.py > > > where food.py is a script that uses the package food. Is it possible > > for this to work in any way? Every time I try to run food.py, python > > tries to import everything from the script instead of from the > > package. How can I fix this? > > Move the code from food.py to food/__init__.py. You can't have a package > and a module with the same name. > > Christian So it is not possible? I don't think moving food.py's code to __init__.py would work out to well, because then how would I run the script? -- http://mail.python.org/mailman/listinfo/python-list
Re: Developing Techniques (and naming conventions)
Adekoba wrote: > food.py > food/ > __init__.py > ham.py > cheese.py > > where food.py is a script that uses the package food. Is it possible > for this to work in any way? Every time I try to run food.py, python > tries to import everything from the script instead of from the > package. How can I fix this? Move the code from food.py to food/__init__.py. You can't have a package and a module with the same name. Christian -- http://mail.python.org/mailman/listinfo/python-list
Developing Techniques (and naming conventions)
I have some questions... Say we have a package "food" food/ __init__.py ham.py cheese.py Is it possible to have a file named "food.py" in the package and have non-referential imports work? i.e., for ham.py to have a line "import food.food". From my experience, python will not work with this. Alright, new scenario. Say we had: food.py food/ __init__.py ham.py cheese.py where food.py is a script that uses the package food. Is it possible for this to work in any way? Every time I try to run food.py, python tries to import everything from the script instead of from the package. How can I fix this? -- http://mail.python.org/mailman/listinfo/python-list
Re: module naming conventions
On Mon, 14 Jan 2008 15:58:49 -0800 (PST), grackle <[EMAIL PROTECTED]> wrote: > On Jan 14, 4:47 pm, Ben Finney <[EMAIL PROTECTED]> > wrote: >> I'm not sure, but it sounds as though you have yet to discover Python >> module packages http://www.python.org/doc/essays/packages.html>. >> They allow a hierarchy of modules in directories. > > I do use packages. I mentioned the Java naming conventions because > they were my first thought for solving the problem of name clashes, > and they work well in some non-Java languages. They don't apply well > to Python, since every top-level module has a unique identity that can > only be specified on one source path. If two libraries use the same > top-level module name, they can't be used together in the same program > without modifying their source code. > > mycompany_mymodulename was just the first solution I thought of that > seemed practical. The mycompany_ prefix protects me from name clashes > with useful modules I might acquire from elsewhere. Seems to me that the Python community solves this as if you had released an executable program for Unix (where all executables end up in /usr/bin or /usr/local/bin, so they have to have unique names). In Linux, I am aware of very few name clashes. People tend to know what names are used and pick other ones. A suite of executables usually share a common prefix (like packages in Python). Some names are a bit far-fetched or silly, of course, but in practice it works reasonably well. /Jorgen -- // Jorgen Grahn R'lyeh wgah'nagl fhtagn! -- http://mail.python.org/mailman/listinfo/python-list
Re: module naming conventions
"Tobiah" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | | > Release your package as free software on the Cheeseshop | > http://cheeseshop.python.org/>. If the name you want is already | > taken, pick one that will help users distinguish yours from the | > existing one. | > | | I like this idea. I developed a library with a name that got | a couple of obscure software related hits on Google. I checked | sourceforge, and found that the name was available, so I stuck | my flag in the dirt. | | It was a python module, so I suppose I will have to look into | the cheeseshop. Is that as open as sourceforge, or is it only | for mature, sophisticated modules? Look at the cheeseshop page, but I would say that 'mature' and 'sophisticated' are too high a bar. 'Potentially useful and not-known-to-be-buggy' should be more like it. -- http://mail.python.org/mailman/listinfo/python-list
Re: module naming conventions
> Release your package as free software on the Cheeseshop > http://cheeseshop.python.org/>. If the name you want is already > taken, pick one that will help users distinguish yours from the > existing one. > I like this idea. I developed a library with a name that got a couple of obscure software related hits on Google. I checked sourceforge, and found that the name was available, so I stuck my flag in the dirt. It was a python module, so I suppose I will have to look into the cheeseshop. Is that as open as sourceforge, or is it only for mature, sophisticated modules? Thanks, Tobiah -- Posted via a free Usenet account from http://www.teranews.com -- http://mail.python.org/mailman/listinfo/python-list
Re: module naming conventions
grackle <[EMAIL PROTECTED]> writes: > On Jan 14, 6:28 pm, Ben Finney <[EMAIL PROTECTED]> > wrote: > > Release your package as free software on the Cheeseshop > > http://cheeseshop.python.org/>. If the name you want is > > already taken, pick one that will help users distinguish yours > > from the existing one. > > Unfortunately, my company thinks it's their software and not mine :-) That's fine. Companies can release (and sell!) freely-licensed software too, and many of them do so. You, as someone who works there and is presumably responsible for this package, have leverage more than anyone else in this discussion to make it happen. -- \"I spent a lot of money on wine and women, and like a fool I | `\ squandered the rest." -- Benny Hill | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: module naming conventions
On Jan 14, 6:28 pm, Ben Finney <[EMAIL PROTECTED]> wrote: > grackle <[EMAIL PROTECTED]> writes: > What do you mean by "top-level module", and "the same top-level name"? > Do you mean "the same fully-qualified name"? If two modules are in > separate places in the hierarchy, they will have different > fully-qualified names. I mean that if I worked at Google (which I don't) and developed google.search and google.officeapps, they would share the same top- level name "google". Because of this, if I wanted to use the two in the same program, they would have to be deployed at the same point in the source path: if I deployed one set of source at src1/google/ search/etc. and the other at src2/google/officeapps/etc. and added src1/ and src2/ to my application's Python source path, one of them would be found and the other not. (Essentially I'd be trying to create two different modules, both named "google", which is nonsense.) I would have to put them in the same source directory and merge the two google/__init__.py files together. I might as well admit that I already made the same mistake in reverse, using a single top-level module for my application, which I now want to split into a group of core application modules and one or more optional, separately-deployed packages. Since I screwed up the first time, I figured I'd get advice before attempting to rectify the situation. My next (slightly more considered, possibly just as naive) impulse is to turn google.search and google.officeapps into google_search and google_officeapps, thereby avoiding name clashes with internal or external projects. (It feels dangerous, not to mention presumptuous, to put generic names like "search" and "officeapps" in the global namespace.) > Release your package as free software on the Cheeseshop > http://cheeseshop.python.org/>. If the name you want is already > taken, pick one that will help users distinguish yours from the > existing one. Unfortunately, my company thinks it's their software and not mine :-) -David -- http://mail.python.org/mailman/listinfo/python-list
Re: module naming conventions
On Jan 14, 11:44 am, grackle <[EMAIL PROTECTED]> wrote: > Obviously Java-style naming is a mistake in Python, since top-level > names have to be unique. Is there a standard naming convention to > facilitate mixing code from different sources, such as > mygroupname_modulename? Is there a best practices guide for module > naming? Not really. Try to pick a unique name for your project. <:\ Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: module naming conventions
grackle <[EMAIL PROTECTED]> writes: > I do use packages. I mentioned the Java naming conventions because > they were my first thought for solving the problem of name clashes, > and they work well in some non-Java languages. They don't apply well > to Python, since every top-level module has a unique identity that > can only be specified on one source path. If two libraries use the > same top-level module name, they can't be used together in the same > program without modifying their source code. What do you mean by "top-level module", and "the same top-level name"? Do you mean "the same fully-qualified name"? If two modules are in separate places in the hierarchy, they will have different fully-qualified names. = $ find foo/ -name '*.py' foo/__init__.py foo/spam.py foo/bar/__init__.py foo/bar/spam.py foo/baz/__init__.py foo/baz/spam.py = = eggs.py = import foo.spam import foo.bar.spam import foo.baz.spam # ... = > mycompany_mymodulename was just the first solution I thought of that > seemed practical. The mycompany_ prefix protects me from name clashes > with useful modules I might acquire from elsewhere. Ah, I see; you're referring to a worldwide package namespace, enforced by the language. AFAIK there's no such thing in Python. > Of course, the best convention is probably the predominant one, and > that's my question: What is the standard way of naming Python > packages? Release your package as free software on the Cheeseshop http://cheeseshop.python.org/>. If the name you want is already taken, pick one that will help users distinguish yours from the existing one. -- \ "If you do not trust the source do not use this program." | `\—Microsoft Vista security dialogue | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: module naming conventions
On Jan 14, 4:47 pm, Ben Finney <[EMAIL PROTECTED]> wrote: > I'm not sure, but it sounds as though you have yet to discover Python > module packages http://www.python.org/doc/essays/packages.html>. > They allow a hierarchy of modules in directories. I do use packages. I mentioned the Java naming conventions because they were my first thought for solving the problem of name clashes, and they work well in some non-Java languages. They don't apply well to Python, since every top-level module has a unique identity that can only be specified on one source path. If two libraries use the same top-level module name, they can't be used together in the same program without modifying their source code. mycompany_mymodulename was just the first solution I thought of that seemed practical. The mycompany_ prefix protects me from name clashes with useful modules I might acquire from elsewhere. There's still a chance of accidental name clashes with other developers in my company, but those can be dealt with. I'm not forced to share a top-level module with every other Python project in the company, so I can develop different projects independently and then import one into the other, without modifying or merging their source. Of course, the best convention is probably the predominant one, and that's my question: What is the standard way of naming Python packages? -David -- http://mail.python.org/mailman/listinfo/python-list
Re: module naming conventions
grackle <[EMAIL PROTECTED]> writes: > Obviously Java-style naming is a mistake in Python, since top-level > names have to be unique. Is there a standard naming convention to > facilitate mixing code from different sources, such as > mygroupname_modulename? Is there a best practices guide for module > naming? I'm not sure, but it sounds as though you have yet to discover Python module packages http://www.python.org/doc/essays/packages.html>. They allow a hierarchy of modules in directories. The Python tutorial http://www.python.org/doc/tut/> will make this and many more fundamental concepts of Python clearer by working through it. Read each section, run every example, and experiment with it until you understand it. Then move on to the next section. Repeat until done. -- \"A hundred times every day I remind myself that [...] I must | `\ exert myself in order to give in the same measure as I have | _o__)received and am still receiving" —Albert Einstein | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
module naming conventions
Obviously Java-style naming is a mistake in Python, since top-level names have to be unique. Is there a standard naming convention to facilitate mixing code from different sources, such as mygroupname_modulename? Is there a best practices guide for module naming? Thanks, David -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
On Jun 8, 2:06 pm, Neil Cerutti <[EMAIL PROTECTED]> wrote:
> On 2007-06-08, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> > Neil Cerutti a écrit :
(snip)
>
> >> Certainly i and j are just as generic, but they have the
> >> advantage over 'item' of being more terse.
>
> > I'm not sure this is really an "advantage" here.
>
> Why not?
>
Because
1/ too much terseness (like too much verbosity) goes against
readability,
2/ 'i' and 'j' are canonical names for C-style for loops indices - and
Python's for(each) loops are very different...
A few special cases aside, one-letter identifiers are bad when it
comes to readability. As far as I'm concern, I stopped using 'j' even
in C code a long time ago - as soon as I have too distinct loop
indices, I can never remember what are 'i' and 'j' supposed to
represent, so I prefer to name them more explicitly (ie : 'row' and
'col').
Just make the test:
for (i=0; i < mi; i++)
for (j-0; j < mj; j++)
f(a[i][j]);
vs
for (row=0; row < nb_rows; row++) {
for (col=0; col < nb_cols; col++) {
init_item_at(grid[row][col]);
}
}
--
http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
On 2007-06-11, Marius Gedminas <[EMAIL PROTECTED]> wrote: > On Jun 6, 3:18 pm, Neil Cerutti <[EMAIL PROTECTED]> wrote: >> > Since 'i' and 'j' are canonically loop indices, I find it >> > totally confusing to use them to name the iteration variable - >> > which is not an index. >> >> Certainly i and j are just as generic, but they have the >> advantage over 'item' of being more terse. > > Python programmers usually prefer readability over terseness. > Finding a variable named 'i' that is not an integer index would > be surprising to me. Terseness and readability can go together in some circumstances, though. But every case should be handled with taste and the application experience, obviously. In a situation where 'i' might be misleading I wouldn't use it. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
On Jun 6, 3:18 pm, Neil Cerutti <[EMAIL PROTECTED]> wrote: > > Since 'i' and 'j' are canonically loop indices, I find it > > totally confusing to use them to name the iteration variable - > > which is not an index. > > Certainly i and j are just as generic, but they have the > advantage over 'item' of being more terse. Python programmers usually prefer readability over terseness. Finding a variable named 'i' that is not an integer index would be surprising to me. -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
On 2007-06-08, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Neil Cerutti a écrit : >> On 2007-06-06, Bruno Desthuilliers >> <[EMAIL PROTECTED]> wrote: >>> Neil Cerutti a écrit : On 2007-06-04, Michael Hoffman <[EMAIL PROTECTED]> wrote: > Wildemar Wildenburger wrote: > I agree with Bruno that i and j should be used only for > indices, but I'm usually less terse than that. I find i and j preferable to overly generic terms like "item." >>> Since 'i' and 'j' are canonically loop indices, I find it >>> totally confusing to use them to name the iteration variable - >>> which is not an index. >>> >>> At least, 'item' suggests that it's an object, and a part of >>> the collection - not just an index you'll have to use to >>> subscript the container. Also, and as far as I'm concerned, I >>> certainly dont find 'i' and 'j' *less* generic than 'item' !-) >> >> Thanks, I didn't say clearly what I meant. >> >> Certainly i and j are just as generic, but they have the >> advantage over 'item' of being more terse. > > I'm not sure this is really an "advantage" here. Why not? -- Neil Cerutti Beethoven's symphonies had more balls, if you will, than say a Mozart. --Music Lit Essay -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
Neil Cerutti a écrit : > On 2007-06-06, Bruno Desthuilliers > <[EMAIL PROTECTED]> wrote: >> Neil Cerutti a écrit : >>> On 2007-06-04, Michael Hoffman <[EMAIL PROTECTED]> wrote: Wildemar Wildenburger wrote: I agree with Bruno that i and j should be used only for indices, but I'm usually less terse than that. >>> I find i and j preferable to overly generic terms like "item." >> Since 'i' and 'j' are canonically loop indices, I find it >> totally confusing to use them to name the iteration variable - >> which is not an index. >> >> At least, 'item' suggests that it's an object, and a part of >> the collection - not just an index you'll have to use to >> subscript the container. Also, and as far as I'm concerned, I >> certainly dont find 'i' and 'j' *less* generic than 'item' !-) > > Thanks, I didn't say clearly what I meant. > > Certainly i and j are just as generic, but they have the > advantage over 'item' of being more terse. I'm not sure this is really an "advantage" here. -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
On 2007-06-06, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Neil Cerutti a écrit : >> On 2007-06-04, Michael Hoffman <[EMAIL PROTECTED]> wrote: >>> Wildemar Wildenburger wrote: >>> I agree with Bruno that i and j should be used only for >>> indices, but I'm usually less terse than that. >> >> I find i and j preferable to overly generic terms like "item." > > Since 'i' and 'j' are canonically loop indices, I find it > totally confusing to use them to name the iteration variable - > which is not an index. > > At least, 'item' suggests that it's an object, and a part of > the collection - not just an index you'll have to use to > subscript the container. Also, and as far as I'm concerned, I > certainly dont find 'i' and 'j' *less* generic than 'item' !-) Thanks, I didn't say clearly what I meant. Certainly i and j are just as generic, but they have the advantage over 'item' of being more terse. I'm in the habit of letting context indicates wether i is a contained object or a subscript. The advantage of a terse, one-letter name is how it draws attention to context, rather than itself. But it's a small distinction. I wouldn't call 'item' a bad choice. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
Ninereeds a écrit : > Google Groups appears to have thrown away my original reply, so sorry > if this appears twice... > > On Jun 4, 9:51 pm, "[EMAIL PROTECTED]" > <[EMAIL PROTECTED]> wrote: > >> 'i' and 'j' are the canonical names for for loops indices in languages >> that don't support proper iteration over a sequence. Using them for >> the iteration variable of a Python for loop (which is really a >> 'foreach' loop) would be at best confusing. > > Without wanting to start a religious war, I disagree. > > In practice, I believe most programmers associate those short names > with pretty much any loop > > variable, irrespective of data type, based primarily on the simple > fact that it's looping > > over a set of values whose meaning is obvious from context. That > declaration is made after > > decades of working with other peoples code as well as my own. The fact that a bad practice is a common practice is by no mean an excuse for promoting this bad practice. FWIW, Python as a very strong philosophy when it comes to readability, and I think it's the first time I see such a naming horror in Python. > > Anyway, why should 'indexes' always be numeric... Because that's part of the commonly admitted definition in the context ? In a dict, it's named a 'key', not an index. And the idiomatic shortcut is 'k', not 'i'. (snip) >> since the use of 'self' is mandatoy. > > That is true, making 'm' prefixes pointless in Python, but that's what > comes from working > > with many different language. Ah, the good old 'I can write basic in any language' syndrom... > You don't always keep them neatly > compartmentalised in your > > head. Habits can be very strong, and there is not always any strong > reason to try to break > them. I do not agree here, but that's another point. The problem is that you are advertising a totally non-pythonic convention on c.l.py. Your post will be archived for years, and some newbie may find it and follow your bad advises. Please keep such advises for where they are appropriate. > Which is why you will still occasionally see 'm' prefixes in > Python code. Never seen such a thing in 7 years of Python programming, and believe me I've read a *lot* of Python code. >> 1/ parameters names *are* local > > As they are in C and C++. The relation between the name and the named object are somewhat different in Python. >> 2/ pythonic methods and functions tends to be short, so you usually >> know which names are params. > > Well written functions and methods in any language tend to be short, For a somewhat different definition of "short". A "short" C functions is commonly tens of lines long - which, by Python standards, starts to become a "too long" function. >> Python has a pretty good support for computed attributes (look for >> 'property'), so you don't need explicit getters/setters. > > I may not use Python as my first and only language, but I have been > using it since version > > 1.4 Then you beat me !-) (started with 1.5.2) > and I am perfectly aware of properties in Python, as I am in other > languages. I am aware, > > for example, that they are relatively new additions to the language, > that they are not used > > in a lot of code, and that you still need named getter and setter > functions to redirect the > > property access to even if these names are only referred to in the > property definition. class SomeClass(object): @apply def some_property(): def fget(self): return self._somevalue def fset(self, newvalue): self._somevalue = newvalue return property(**locals()) Yes, true, the getter and the setter are named. But here, you don't even have to worry a millisecond about how to name them. > All of which is mostly besides the point. More and more programmers > are multilingual these > days, So am I. > and scripting languages such as Python are more likely second > languages than first. 'second' by usage frequency or by learning order ? > Having a hard rule that conventions from one language should never > leak into another, "never" ? Python stole almost anything - naming convention included - from other languages. It's not a matter of "purity", it's a matter of filtering what makes sens and what doesn't. > are common in many languages. Thorsten was having difficulty in > finding distinct names, and I > described a common naming convention that is often useful for this. I > don't think I was wrong > to do that. See my comments above. If these conventions are totally alien to Python (and have already been abandonned/rejected by people with similar background as yours - strange enough, a lot of people here are C, C++ or Java coders too), then as far as I'm concerned, yes, you are wrong to advertise them here. Call me a purist if you want... (and please don't take my remarks as a personal offense - it's just that I happen to be have *very* strong opinions on some points). -- http://mail.pytho
Re: *Naming Conventions*
Neil Cerutti a écrit : > On 2007-06-04, Michael Hoffman <[EMAIL PROTECTED]> wrote: >> Wildemar Wildenburger wrote: >>> While that is true, I guess it is commonplace to use i, j, k >>> and n (maybe others) in constructs like >>> >>> for i in range(len(data)): >>>do_stuff(data[i]) >>> >>> Or should the good python hacker do that differently? Hope not >>> ;). >> Well, yes, I would do: >> >> for item in data: >> do_stuff(item) >> >> or, if using enumerate: >> >> for item_index, item in enumerate(data): >> do_stuff(item_index, item) >> >> I agree with Bruno that i and j should be used only for >> indices, but I'm usually less terse than that. > > I find i and j preferable to overly generic terms like "item." > Since 'i' and 'j' are canonically loop indices, I find it totally confusing to use them to name the iteration variable - which is not an index. At least, 'item' suggests that it's an object, and a part of the collection - not just an index you'll have to use to subscript the container. Also, and as far as I'm concerned, I certainly dont find 'i' and 'j' *less* generic than 'item' !-) I agree that except for uber-generic code or quick throw-away script 'item' is probably not a very good name, but then nor are 'i' and 'j'... -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
Google Groups appears to have thrown away my original reply, so sorry
if this appears twice...
On Jun 4, 9:51 pm, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> 'i' and 'j' are the canonical names for for loops indices in languages
> that don't support proper iteration over a sequence. Using them for
> the iteration variable of a Python for loop (which is really a
> 'foreach' loop) would be at best confusing.
Without wanting to start a religious war, I disagree.
In practice, I believe most programmers associate those short names
with pretty much any loop
variable, irrespective of data type, based primarily on the simple
fact that it's looping
over a set of values whose meaning is obvious from context. That
declaration is made after
decades of working with other peoples code as well as my own.
Don't believe me? Take a look at some code that uses C++ iterators,
for example, or some C
code that uses pointers as iterators, or some Ada code that loops over
an enumerated type,
etc etc. It won't find you long to realise that 'i' and 'j' are very
common names for those
too.
I've seen 'i' used in "iterations" over lists in Scheme, OCaml and
Haskell, whether done
using tail recursion or list comprehensions or whatever. 'x' is more
common, as with 'x:xs'
patterns used to pick the head 'x' from a list in OCaml or Haskell,
but then 'x' looks
scarily like an ordinate we can't have that ;-)
Anyway, why should 'indexes' always be numeric...
> > for i in validanswers:
> > if myAnswers.current in myAnswers.validList [i]:
> > MyOptions['style'] = i
>
> And this is *exactly* what one should not do in Python. If you want a
> generic name here, use 'item' instead.
In this code, 'i' is appears to be just an answer identifier. It is
used to identify for
which answer in the validList you are looking for. It may well even be
a numeric index (or
some other kind of key), from what we can see in the example.
"item" says nothing that "i" does not. If nothing else, you could
always say that 'i' is
short for 'item' or 'id' or whatever.
> since the use of 'self' is mandatoy.
That is true, making 'm' prefixes pointless in Python, but that's what
comes from working
with many different language. You don't always keep them neatly
compartmentalised in your
head. Habits can be very strong, and there is not always any strong
reason to try to break
them. Which is why you will still occasionally see 'm' prefixes in
Python code.
Actually, in *my* Python code you're still more likely to see
'f' (standing for field)
prefixes - a convention I adopted in C++ at a time when I thought 'm'
better suited macros,
and when I'd never yet seen the 'm' for member prefix since most C++
code I'd seen still used
the Hungarian conventions. It's a bad habit that I still haven't fully
broken.
> 1/ parameters names *are* local
As they are in C and C++. Not just in terms of scoping, but in terms
of being local variables
too...
int factorial (int p)
{
int l = 1;
while (p > 1) { l *= p; p--; }
return l;
}
def factorial (p) :
l = 1
while p > 1 : l *= p; p -= 1
return l
Updating parameters when you could just as easily update locals is of
course bad style in
either language - and some would say that any updating of parameters
is bad style - but the
point is that C and Python do the same thing.
This example does illustrate another useful fact about the 'l' and 'p'
prefixes - there are
times when the prefix is all you need to specify the whole name, since
there really is
nothing else that can be usefully be said.
> 2/ pythonic methods and functions tends to be short, so you usually
> know which names are params.
Well written functions and methods in any language tend to be short,
but even so, there are
times when a convention that distinguishes the two kinds of names
without needing to think up
distinct names is convenient. I wasn't suggesting that this convention
should be universally
adopted in Python or that it was relevant to Thorstens example even -
but it is common in
many languages (not just C++), and it does sometimes help resolve the
how-can-I-give-these-meaningfully-different-names issue.
> Python has a pretty good support for computed attributes (look for
> 'property'), so you don't need explicit getters/setters.
I may not use Python as my first and only language, but I have been
using it since version
1.4 and I am perfectly aware of properties in Python, as I am in other
languages. I am aware,
for example, that they are relatively new additions to the language,
that they are not used
in a lot of code, and that you still need named getter and setter
functions to redirect the
property access to even if these names are only referred to in the
property definition.
All of which is mostly besides the point. More and more programmers
are multilingual these
days, and scripting languages such as Python are more likely second
languages than first.
Having a hard rule
Re: *Naming Conventions*
Neil Cerutti wrote: > I find i and j preferable to overly generic terms like "item." Well, I probably wouldn't use "item" in a real example, unless it were for a truly generic function designed to act on all sequences. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
On 2007-06-04, Michael Hoffman <[EMAIL PROTECTED]> wrote: > Wildemar Wildenburger wrote: >> While that is true, I guess it is commonplace to use i, j, k >> and n (maybe others) in constructs like >> >> for i in range(len(data)): >>do_stuff(data[i]) >> >> Or should the good python hacker do that differently? Hope not >> ;). > > Well, yes, I would do: > > for item in data: > do_stuff(item) > > or, if using enumerate: > > for item_index, item in enumerate(data): > do_stuff(item_index, item) > > I agree with Bruno that i and j should be used only for > indices, but I'm usually less terse than that. I find i and j preferable to overly generic terms like "item." -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
Carsten Haese wrote: > On Mon, 2007-06-04 at 23:20 +0200, Wildemar Wildenburger wrote: > >> I guess it is commonplace to use i, j, k and n >> (maybe others) in constructs like >> >> for i in range(len(data)): >> do_stuff(data[i]) >> >> Or should the good python hacker do that differently? Hope not ;). >> > > That's a big, fat "Heck, Yes": > > for thing in data: >do_stuff(thing) > > Boy is my face red! Holy Moly ... that was so obvious! See, that's what you get for coding too much matlab! Screw that! /W -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
Wildemar Wildenburger wrote: > [EMAIL PROTECTED] wrote: >> On Jun 4, 12:20 am, Ninereeds <[EMAIL PROTECTED]> wrote: >> >>> First, for small loops with loop variables whose meaning is obvious >>> from context, the most readable name is usually something like 'i' or >>> 'j'. >>> >> >> 'i' and 'j' are the canonical names for for loops indices in languages >> that don't support proper iteration over a sequence. Using them for >> the iteration variable of a Python for loop (which is really a >> 'foreach' loop) would be at best confusing. >> >> > > While that is true, I guess it is commonplace to use i, j, k and n > (maybe others) in constructs like > > for i in range(len(data)): >do_stuff(data[i]) > > Or should the good python hacker do that differently? Hope not ;). Well, yes, I would do: for item in data: do_stuff(item) or, if using enumerate: for item_index, item in enumerate(data): do_stuff(item_index, item) I agree with Bruno that i and j should be used only for indices, but I'm usually less terse than that. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
On Mon, 2007-06-04 at 23:20 +0200, Wildemar Wildenburger wrote: > I guess it is commonplace to use i, j, k and n > (maybe others) in constructs like > > for i in range(len(data)): > do_stuff(data[i]) > > Or should the good python hacker do that differently? Hope not ;). That's a big, fat "Heck, Yes": for thing in data: do_stuff(thing) -- Carsten Haese http://informixdb.sourceforge.net -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
[EMAIL PROTECTED] wrote: > On Jun 4, 12:20 am, Ninereeds <[EMAIL PROTECTED]> wrote: > >> First, for small loops with loop variables whose meaning is obvious >> from context, the most readable name is usually something like 'i' or >> 'j'. >> > > 'i' and 'j' are the canonical names for for loops indices in languages > that don't support proper iteration over a sequence. Using them for > the iteration variable of a Python for loop (which is really a > 'foreach' loop) would be at best confusing. > > While that is true, I guess it is commonplace to use i, j, k and n (maybe others) in constructs like for i in range(len(data)): do_stuff(data[i]) Or should the good python hacker do that differently? Hope not ;). /W -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
On Jun 4, 12:20 am, Ninereeds <[EMAIL PROTECTED]> wrote:
> On Jun 4, 5:03 am, Thorsten Kampe <[EMAIL PROTECTED]> wrote:
>
> > for validanswer in validanswers:
> > if myAnswers.myanswer in myAnswers.validAnswers[validanswer]:
> > MyOptions['style'] = validanswer
>
> First, for small loops with loop variables whose meaning is obvious
> from context, the most readable name is usually something like 'i' or
> 'j'.
'i' and 'j' are the canonical names for for loops indices in languages
that don't support proper iteration over a sequence. Using them for
the iteration variable of a Python for loop (which is really a
'foreach' loop) would be at best confusing.
(snip)
> Based on this, your code might become something like...
>
> for i in validanswers:
> if myAnswers.current in myAnswers.validList [i]:
> MyOptions['style'] = i
And this is *exactly* what one should not do in Python. If you want a
generic name here, use 'item' instead.
> It is also often useful to use a convention where a prefix identifies
> whether a name is a (p)arameter, (l)ocal variable, or (m)ember
You don't have to use any kind of prefix for attributes ('member' is
not a Python idiom - remember that in Python, a method is also an
attribute...) since the use of 'self' is mandatoy.
And you usually don't need to distinguish 'local' from 'parameters',
since
1/ parameters names *are* local
2/ pythonic methods and functions tends to be short, so you usually
know which names are params.
FWIW, prefixing names this way is something I've almost never seen in
Python code.
> variable - no prefix for functions, usually. For example, a simple
> setter method
Python has a pretty good support for computed attributes (look for
'property'), so you don't need explicit getters/setters.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Dict naming, global vs local imports, etc. [was Re: *Naming Conventions*]
In <[EMAIL PROTECTED]>, George Sakkis wrote: > While we're at it, although it's not strictly a naming convention > issue I still waste brain cycles on where to put the import statements > that are used only once or twice in a module. Should > (1) all imports be at the global scope at the top of the module, or > (2) be imported in the function or method they are actually used ? > > […] > > Reasons for (2) > --- > - Point of import closer to point of use; easy to notice if a given > import is not used any more after refactoring. `pylint` reports unused imported names. I don't follow PEP8 only if it's not possible otherwise. But cyclic imports are bad anyway. :-) And if the import is *really* expensive and only needed in some special circumstances. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
Michael Hoffman wrote: > Thorsten Kampe wrote: > >> for validanswer in validanswers: >> if myAnswers.myanswer in myAnswers.validAnswers[validanswer]: >> MyOptions['style'] = validanswer > > I usually try to avoid using "my" because I find it obscures a better > understanding of what is really going ...on. Whoops, sorry about missing the last word of that message. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
Thorsten Kampe wrote: > for validanswer in validanswers: > if myAnswers.myanswer in myAnswers.validAnswers[validanswer]: > MyOptions['style'] = validanswer I usually try to avoid using "my" because I find it obscures a better understanding of what is really going -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
--- Dan Bishop <[EMAIL PROTECTED]> wrote: > > * Loop indices often have single-letter names > (typically i/j/k or x/ > y), or names that are the singular form of the list > name (e.g., "for > ballot in self._ballots"). For iterating over > files, I use "line". > You are in good company with "i" and "line." They are among the 15 most used tokens in the Python standard library, which includes reserved words if, def, return, in, not, else, and for. 16610 self 7347 if 5222 def 4686 return 2818 None 2235 in 1799 not 1723 else 1637 name 1499 i 1226 os 1224 line 1203 for 1183 data 1181 path I sampled /usr/local/lib/python2.5 with tokenizer. Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
On Jun 3, 11:03 pm, Thorsten Kampe <[EMAIL PROTECTED]> wrote: > Okay, > > I hear you saying 'not another naming conventions thread'. I've read > through Google and the 'naming conventions' threads were rather > *spelling conventions* threads. > > I'm not interested in camelCase versus camel_case or anything > mentioned in 'PEP 8 -- Style Guide for Python Code'. What I'm looking > for is hints or ideas how to name your variables and especially how to > name functions, methods and classes. In my code: * The most common form of a function/method name is verb_noun. Other common patterns are adjective_noun, noun_to_noun or noun2noun (for conversions), and noun_of_noun. * Classes nearly always have AdjectiveNoun names. * Loop indices often have single-letter names (typically i/j/k or x/ y), or names that are the singular form of the list name (e.g., "for ballot in self._ballots"). For iterating over files, I use "line". -- http://mail.python.org/mailman/listinfo/python-list
Dict naming, global vs local imports, etc. [was Re: *Naming Conventions*]
On Jun 3, 4:32 pm, Steve Howell <[EMAIL PROTECTED]> wrote:
> I also still waste brain cycles on naming
> dictionaries. Sometimes I name the dictionary after
> the values it stores, sometimes after the keys it
> uses, and sometimes after both.
I was in the same boat but now I've pretty much settled to the
convention `key2value`, e.g.:
name2func = {
'sum' : sum,
'avg' : lambda values: sum(values) / float(len(values))
'product' : lambda values: reduce(operator.mul,values,1),
}
word2positions = {
'dog' : [3, 45, 79, 840],
'cat' : [56, 97, 810],
}
At some point I was torn between this and the plural form, i.e.
`keys2values`, but that's ambiguous in cases where each key or value
is a collection, such as the 'positions' above.
While we're at it, although it's not strictly a naming convention
issue I still waste brain cycles on where to put the import statements
that are used only once or twice in a module. Should
(1) all imports be at the global scope at the top of the module, or
(2) be imported in the function or method they are actually used ?
Reasons for (1)
---
- PEP-8 compatible.
- Easy to see all external dependencies in one place.
Reasons for (2)
---
- Point of import closer to point of use; easy to notice if a given
import is not used any more after refactoring.
- Less name pollution.
- Faster name lookup in locals (might make a difference for tight
loops).
I usually go for (1), at least until the number of global imports in
the top remains in single digits. After some point though I often
localize the standard library imports that are used only once or twice
(the third-party and local application imports are almost always
global). Any others that are not strictly PEP-8 compliant on this ?
George
--
http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
On Jun 4, 5:03 am, Thorsten Kampe <[EMAIL PROTECTED]> wrote: > for validanswer in validanswers: > if myAnswers.myanswer in myAnswers.validAnswers[validanswer]: > MyOptions['style'] = validanswer First, for small loops with loop variables whose meaning is obvious from context, the most readable name is usually something like 'i' or 'j'. It avoids unnecessary duplication and clutter. Of course, just as physically turning your head to look in the rear view mirror is necessary in a driving test but stupid for real driving, you are likely to be penalised for this if you do it in an educational setting or somewhere else where daft coding conventions are strictly enforced (I once worked in a company that had library constants 'Zero' and 'One' defined because the coding conventions insisted on absolutely no unnamed 'magic numbers' - spelling the numbers using letters apparently didn't count). Second, when naming a member, you should take into account that references will already be specifying what the whole class describes. That is, provide new information where possible, and avoid unnecessary repetition. Since Python is dynamically typed, it can be useful for names to describe the datatype of the content at times (though not to the Hungarian notation extreme that is common is C code, esp. for Windows). And while most variable names are nouns, sometimes adjectives are most appropriate - esp where the noun is already clear from context. Based on this, your code might become something like... for i in validanswers: if myAnswers.current in myAnswers.validList [i]: MyOptions['style'] = i 'i' Its obviously a validanswer since it is one of the validanswers. 'myAnswers.current' I know its related to myAnswers, but the adjective 'current' tells me more about this specific member. 'myAnswers.validList' 'valid' on its own is useful extra information, but suggests a flag field. validList is better since it avoids that confusion. Depending on what myAnswers.myanswer actually holds, it might alternately be renamed something like myAnswers.uid or myAnswers.id (a [unique] identifier code identifying the answer) or myAnswers.text (the text of the answer). It is also often useful to use a convention where a prefix identifies whether a name is a (p)arameter, (l)ocal variable, or (m)ember variable - no prefix for functions, usually. For example, a simple setter method may logically use the same name for the parameter specifying the value to write, the member variable to write to, and (barring a prefix along the lines of 'Set') the method name. -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
--- Thorsten Kampe <[EMAIL PROTECTED]> wrote: > > for validanswer in validanswers: > if myAnswers.myanswer in > myAnswers.validAnswers[validanswer]: > MyOptions['style'] = validanswer > I can at least sympathize with your problem, although I don't have a great solution for you. I often have trios of variables like this: answer_dct answers answer English mostly pluralizes with an "s," but I sometimes resort to bad English to keep the convention going: mouse_dct mouses (not mice) mouse I also still waste brain cycles on naming dictionaries. Sometimes I name the dictionary after the values it stores, sometimes after the keys it uses, and sometimes after both. Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz -- http://mail.python.org/mailman/listinfo/python-list
Re: *Naming Conventions*
In <[EMAIL PROTECTED]>, Thorsten Kampe wrote: > Recently I wrote this code and noticed that I was completely lost in > giving these objects names to describe and distinguish them: > > for validanswer in validanswers: > if myAnswers.myanswer in myAnswers.validAnswers[validanswer]: > MyOptions['style'] = validanswer Wow, I know you don't want to talk about "spelling conventions" but here you are mixing many of them. :-) I don't know if it makes sense for your code, but maybe you can move the ``if`` condition into the class of `myAnswer` as overloaded ``in`` operator. Then this can be written as: for valid_answer in valid_answers: if valid_answer in my_answers: my_options['style'] = valid_answer > The 'tips' I got through some postings or articles on the net are: if > a function simply tests something and returns a boolean call it > > def is_(): > pass The other typical boolean test prefix is 'has_'. > like 'is_even'. > > Makes sense. The other thing I captured was to use something like > > def get_values(): > > ... Makes sense, too, but aren't all functions getting something? So you may reduce this to just `values()`. On the other hand there is the convention to name functions and methods as verbs that are "doing" something. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
*Naming Conventions*
Okay, I hear you saying 'not another naming conventions thread'. I've read through Google and the 'naming conventions' threads were rather *spelling conventions* threads. I'm not interested in camelCase versus camel_case or anything mentioned in 'PEP 8 -- Style Guide for Python Code'. What I'm looking for is hints or ideas how to name your variables and especially how to name functions, methods and classes. I know this depends on what the function is doing. If I know what it is doing I should be able to give them a desciptive name. But actually I'm often not able. Especially when the task is quite similar to another function or Class. Recently I wrote this code and noticed that I was completely lost in giving these objects names to describe and distinguish them: for validanswer in validanswers: if myAnswers.myanswer in myAnswers.validAnswers[validanswer]: MyOptions['style'] = validanswer The 'tips' I got through some postings or articles on the net are: if a function simply tests something and returns a boolean call it def is_(): pass like 'is_even'. Makes sense. The other thing I captured was to use something like def get_values(): ... Makes sense, too, but aren't all functions getting something? So if someone had a similar dilemma to mine and could tell me how he dealt with that, I'd be grateful... Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming conventions
On 2006-08-30, Chaz Ginger <[EMAIL PROTECTED]> wrote: > Neil Cerutti wrote: >> The first time I saw StudlyCaps I thought it was the ugliest >> thing I'd ever seen. Now I use it a lot. I still have trouble >> with GVR's preference for HTTPServer over HttpServer. The >> latter is, to me, easier to read and write. > > Personally I think so long as you are consistent in your coding > style, be it httpserver, HttpServer or HTTPServer or any other > variation, the reader will soon figure out what it means. > > If you feel you are being held hostage to capitalized naming > conventions you might want to consider having things end in > ...Class or ...Instance. I used a Python library (PAWS: Roger Plowman's interesting Interactive Fiction library) that used that convention. It annoyed and stupefied me. > At least you would be doing what you say you want to do: making > the code more maintainable. Otherwise I say just be consistent > and don't let dogma get in the way. > > All those that remember "Hungarian notation" please stand up! v_stand(p_self, d_up). -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming conventions
Neil Cerutti wrote: > On 2006-08-30, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: >> On Wed, 30 Aug 2006 14:22:16 +1000, Ben Finney <[EMAIL PROTECTED]> wrote: >>> "glenn" <[EMAIL PROTECTED]> writes: >>> >>>> Bruno Desthuilliers wrote: >>>>> It might be better to use newstyle classes if you can. Also, the >>>>> convention is to use CamelCase for classes names (unless you have >>>>> a strong reason to do otherwise). >>> Note that this style is more correctly called TitleCase, since the >> Or StudlyCaps :) > > The first time I saw StudlyCaps I thought it was the ugliest > thing I'd ever seen. Now I use it a lot. I still have trouble > with GVR's preference for HTTPServer over HttpServer. The latter > is, to me, easier to read and write. > Personally I think so long as you are consistent in your coding style, be it httpserver, HttpServer or HTTPServer or any other variation, the reader will soon figure out what it means. If you feel you are being held hostage to capitalized naming conventions you might want to consider having things end in ...Class or ...Instance. At least you would be doing what you say you want to do: making the code more maintainable. Otherwise I say just be consistent and don't let dogma get in the way. All those that remember "Hungarian notation" please stand up! -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming conventions (was: Re: refering to base classes)
On 2006-08-30, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On Wed, 30 Aug 2006 14:22:16 +1000, Ben Finney <[EMAIL PROTECTED]> wrote: >>"glenn" <[EMAIL PROTECTED]> writes: >> >>> Bruno Desthuilliers wrote: >>> > It might be better to use newstyle classes if you can. Also, the >>> > convention is to use CamelCase for classes names (unless you have >>> > a strong reason to do otherwise). >> >>Note that this style is more correctly called TitleCase, since the > > Or StudlyCaps :) The first time I saw StudlyCaps I thought it was the ugliest thing I'd ever seen. Now I use it a lot. I still have trouble with GVR's preference for HTTPServer over HttpServer. The latter is, to me, easier to read and write. -- Neil Cerutti These people haven't seen the last of my face. If I go down, I'm going down standing up. --Chuck Person -- http://mail.python.org/mailman/listinfo/python-list
Re: Naming conventions
Ben Finney wrote:
> "glenn" <[EMAIL PROTECTED]> writes:
>
>> Bruno Desthuilliers wrote:
>>> It might be better to use newstyle classes if you can. Also, the
>>> convention is to use CamelCase for classes names (unless you have
>>> a strong reason to do otherwise).
>
> Note that this style is more correctly called TitleCase, since the
> first letter of *every* word is capitalised, like in a headline (or
> title). "camel case" is different -- see below.
Oops, sorry - my mistake.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
Re: Naming conventions (was: Re: refering to base classes)
On Wed, 30 Aug 2006 14:22:16 +1000, Ben Finney <[EMAIL PROTECTED]> wrote: >"glenn" <[EMAIL PROTECTED]> writes: > >> Bruno Desthuilliers wrote: >> > It might be better to use newstyle classes if you can. Also, the >> > convention is to use CamelCase for classes names (unless you have >> > a strong reason to do otherwise). > >Note that this style is more correctly called TitleCase, since the Or StudlyCaps :) >first letter of *every* word is capitalised, like in a headline (or >title). "camel case" is different -- see below. > >> ohh - interesting. Thanks for the camelCase tip - dont have a good >> reason to do otherwise, just bad habits. > >The style called camelCase (all words run together, capitalise first >letter of every word except the first) is prevalent in Java, where it >denotes the name of an *instance*, in contrast to a *class* which is >named with TitleCase. > >The camelCase style is less popular in the Python world, where (as per >PEP 8) instances are named with all lower case, either joinedwords or >separate_by_underscores. Not that this prevents all projects, even some large ones, from going with a more camelCased convention. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Naming conventions (was: Re: refering to base classes)
"glenn" <[EMAIL PROTECTED]> writes: > Bruno Desthuilliers wrote: > > It might be better to use newstyle classes if you can. Also, the > > convention is to use CamelCase for classes names (unless you have > > a strong reason to do otherwise). Note that this style is more correctly called TitleCase, since the first letter of *every* word is capitalised, like in a headline (or title). "camel case" is different -- see below. > ohh - interesting. Thanks for the camelCase tip - dont have a good > reason to do otherwise, just bad habits. The style called camelCase (all words run together, capitalise first letter of every word except the first) is prevalent in Java, where it denotes the name of an *instance*, in contrast to a *class* which is named with TitleCase. The camelCase style is less popular in the Python world, where (as per PEP 8) instances are named with all lower case, either joinedwords or separate_by_underscores. -- \"Crime is contagious ... if the government becomes a | `\lawbreaker, it breeds contempt for the law." -- Justice Louis | _o__) Brandeis | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Request for help on naming conventions
On Monday 13 June 2005 03:59 am, Steven D'Aprano wrote:
> Are there any useful naming conventions for modules, classes and functions?
>
> For instance, should I name functions as verbs and classes as nouns?
Hmm. Okay, here's a few I use:
Classes are generally: Capitalized or CapWords and I use nouns.
Unless it's a "mix-in" in which case, I use adjectives. This mirrors
usage in the Zope sources, BTW.
Method names are either: funkyCaps (Zope uses this) or
lower_case_with_underscores.
I use verb names for methods and functions with very few exceptions.
I use nouns or occasionally adjectives for attributes.
Constants or enumeration values are ALLCAPS or ALL_CAPS, and
usually I define them within a namespace with a descriptive, all lower
case name (a trivial class). The enumeration is usually abbreviated,
but would be an adjective, e.g.:
color.RED
I use *plural* names for lists and tuples, but singular names for
mappings. This is so that I can use the singular in the loop:
for book in books:
pass
But I use single character variables in list comprehensions (and
generators, except I haven't used them yet):
late_books = [b for b in books if b.duedate < datetime.now()]
I also use single-character names in highly mathematical code:
def dot_product(a,b):
return a.x*b.x + a.y*b.y + a.z*b.z
But if a variable is going to be used more than about 20 lines
away from where it is defined, I use a descriptive word instead.
I like to use Capital or CapWords for modules, too, although I'm
beginning to wonder about that practice.
I really hate redundancy like this:
Topic.create_topic()
and usually prefer:
Topic.create()
which of course means, I have to qualify things a lot in my code.
This has never been an issue, but if it did, I would just introduce
an intermediary like this ("_" for "."):
Topic_create = Topic.create
After that, it's kind of case-by-case. Do read PEP 8, too, of
course.
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Request for help on naming conventions
Steven D'Aprano wrote: > Are there any useful naming conventions for modules, classes and > functions? > > For instance, should I name functions as verbs and classes as nouns? > > eg > class Transformer(): > pass > > def transform(): > do_stuff > > What about the module name? transformations.py or transform.py? You probably want to read the PEP 8, "Style Guide for Python Code": http://www.python.org/peps/pep-0008.html > What do people do with their own code? Do folks find that being > consistent helps them remember what is what, or do you name objects > whatever feels right at the time? Naming convention are mostly a matter of personal taste (unless you are working in a larger team, where there are some official conventions that must be followed). So I would say the 'feels right' is the most important factor. -- Benjamin Niemann Email: pink at odahoda dot de WWW: http://www.odahoda.de/ -- http://mail.python.org/mailman/listinfo/python-list
Request for help on naming conventions
Are there any useful naming conventions for modules, classes and functions? For instance, should I name functions as verbs and classes as nouns? eg class Transformer(): pass def transform(): do_stuff What about the module name? transformations.py or transform.py? What do people do with their own code? Do folks find that being consistent helps them remember what is what, or do you name objects whatever feels right at the time? -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: Library Naming Conventions.
[EMAIL PROTECTED] wrote: > quoting: > > Modules should have short, lowercase names, without underscores. > > this still doesn't explain Cookie. PEP-008 didn't exist since the beginning of Python's development. Cookie (I believe) predates PEP-008. -- Robert Kern [EMAIL PROTECTED] "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: Library Naming Conventions.
[EMAIL PROTECTED] wrote: > quoting: > > Modules should have short, lowercase names, without underscores. > > this still doesn't explain Cookie. the document you're quoting also says: This document was adapted from Guido's original Python Style Guide essay[2] where [2] points to a document that says: Module names can be either MixedCase or lowercase. There is no unambiguous convention to decide which to use. Modules that export a single class (or a number of closely related classes, plus some additional support) are often named in MixedCase, with the module name being the same as the class name (e.g. the standard StringIO module). Modules that export a bunch of functions are usually named in all lowercase. -- http://mail.python.org/mailman/listinfo/python-list
Re: Library Naming Conventions.
[EMAIL PROTECTED] wrote: > quoting: > > Modules should have short, lowercase names, without underscores. > > this still doesn't explain Cookie. Sure it does. The subject line says "conventions", and a convention isn't a firm rule, just something many people agree on. Obviously the author of Cookie has different preferences. Nobody is bound by a convention. The PEP describes what is widespread but not universal preference, that's all. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Library Naming Conventions.
quoting: Modules should have short, lowercase names, without underscores. this still doesn't explain Cookie. [EMAIL PROTECTED] wrote: > see http://www.python.org/peps/pep-0008.html for naming conventions and > other style issues -- http://mail.python.org/mailman/listinfo/python-list
