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 argumen
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
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
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
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
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 fo
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
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 ha
* 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
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
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:
--
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 confli
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
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.pythonc
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
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"
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 "
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
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
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
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 --n
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 wi
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.
>
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
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
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
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 fr
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 stupi
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 wi
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" f
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?
"s
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 he
* 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
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
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
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 tryi
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
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
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
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?)
>>>
>>>
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 does
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 yo
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
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
> regula
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 "m
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
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
-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
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.
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
> p
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 wo
ays/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'
"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 li
> 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 softwa
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
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
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 prac
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
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 me
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 mod
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.py
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 rea
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
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'
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
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 usual
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.
>>
>>
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 i
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 shou
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 th
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
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 th
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?
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
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 "
[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 lo
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 loop
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 th
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
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
--- 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"
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.
>
&g
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 settl
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
--- 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 o
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]:
> M
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 --
r. 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 bei
rite.
>
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
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 i
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
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 r
"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
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
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
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
[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 th
[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
[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
auth
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
1 - 100 of 103 matches
Mail list logo
