RE: If/then style question

-Original Message- What about, def myMethod(): for condition, exitCode in [ (cond1, 'error1'), (cond2, 'very bad error'), ]: if not condition: break else: do_some_usefull_stuff() # executed only if the we never hit the break

Re: If/then style question

John Gordon wrote: (This is mostly a style question, and perhaps one that has already been discussed elsewhere. If so, a pointer to that discussion will be appreciated!) When I started learning Python, I wrote a lot of methods that looked like this: def myMethod(self, arg1, arg2): if

Re: If/then style question

On Thu, 16 Dec 2010 20:32:29 -0800, Carl Banks wrote: > Even without the cleanup issue, sometimes you want to edit a function to > affect all return values somehow. If you have a single exit point you > just make the change there; if you have mulitple you have to hunt them > down and change all o

Re: If/then style question

On 12/16/2010 11:32 PM, Carl Banks wrote: > On Dec 16, 2:56 pm, Ryan Kelly wrote: >> On Thu, 2010-12-16 at 21:49 +, John Gordon wrote: >>> (This is mostly a style question, and perhaps one that has already been >>> discussed elsewhere. If so, a pointer

Re: If/then style question

On Dec 16, 2:56 pm, Ryan Kelly wrote: > On Thu, 2010-12-16 at 21:49 +, John Gordon wrote: > > (This is mostly a style question, and perhaps one that has already been > > discussed elsewhere.  If so, a pointer to that discussion will be > > appreciated!) > > > Whe

Re: If/then style question

"Steven D'Aprano" wrote in message news:4d0aa5e7$0$29997$c3e8da3$54964...@news.astraweb.com... It doesn't look like you were learning Python. It looks like you were learning C with Python syntax :( True, although in many cases one has to interface to legacy C code where it'd be rather more co

Re: If/then style question

John Gordon wrote: > But lately I've been preferring this style: > >   def myMethod(self, arg1, arg2): > >     if some_bad_condition: >       return bad1 > >     elif some_other_bad_condition: >       return bad2 > >     elif yet_another_bad_condition: >       return bad3 > >     do_some_useful_st

Re: If/then style question

On Thu, 16 Dec 2010 21:49:07 +, John Gordon wrote: > (This is mostly a style question, and perhaps one that has already been > discussed elsewhere. If so, a pointer to that discussion will be > appreciated!) > > When I started learning Python, I wrote a lot of methods tha

Re: If/then style question

On Thu, Dec 16, 2010 at 3:41 PM, Stefan Sonnenberg-Carstens wrote: > return [x for x,y in > ((bad1,some_bad_condition),(bad2,some_other_bad_condition),(bad3,yet_another_bad_condition),(good1,do_some_useful_stuff() > or True)) if x][0] This doesn't work. do_some_usefull_stuff() gets called during

Re: If/then style question

On Thu, 2010-12-16 at 21:49 +, John Gordon wrote: > (This is mostly a style question, and perhaps one that has already been > discussed elsewhere. If so, a pointer to that discussion will be > appreciated!) > > When I started learning Python, I wrote a lot of methods that loo

Re: If/then style question

Am 16.12.2010 22:49, schrieb John Gordon: (This is mostly a style question, and perhaps one that has already been discussed elsewhere. If so, a pointer to that discussion will be appreciated!) When I started learning Python, I wrote a lot of methods that looked like this: def myMethod

Re: If/then style question

On 2010-12-16, John Gordon wrote: > (This is mostly a style question, and perhaps one that has already been > discussed elsewhere. If so, a pointer to that discussion will be > appreciated!) > > When I started learning Python, I wrote a lot of methods that looked like >

Re: If/then style question

On 2010-12-16, John Gordon wrote: > I like this style more, mostly because it eliminates a lot of indentation. > > However I recall one of my college CS courses stating that "one entry, > one exit" was a good way to write code, and this style has lots of exits. So, take the good intentation from

Re: If/then style question

John Gordon wrote: (This is mostly a style question, and perhaps one that has already been discussed elsewhere. If so, a pointer to that discussion will be appreciated!) When I started learning Python, I wrote a lot of methods that looked like this: def myMethod(self, arg1, arg2): if

If/then style question

(This is mostly a style question, and perhaps one that has already been discussed elsewhere. If so, a pointer to that discussion will be appreciated!) When I started learning Python, I wrote a lot of methods that looked like this: def myMethod(self, arg1, arg2): if some_good_condition

Re: Style question for conditional execution

On Nov 25, 7:43 am, Paul Rubin wrote: > Gerald Britton writes: > >     if v: > >         f() > > > I might, however, think more in a functional-programming direction. > > Then I might write: > > >     v and f() > > Python has conditional expressions.  The above would be: > >     f() if v else Non

Re: Style question for conditional execution

Gerald Britton writes: > if v: > f() > > I might, however, think more in a functional-programming direction. > Then I might write: > > v and f() Python has conditional expressions. The above would be: f() if v else None using "and" is bug-prone. -- http://mail.python.org/m

Re: Style question for conditional execution

Gerald Britton writes: > Writing in Python gives me the luxury of choosing different paradigms > for similar operations. Lately I've been thinking about a minor > detail that peaked my interest and am curious what others think: > > Say that I have some function "f" that I will execute if some va

Re: Style question for conditional execution

Both paradigms are in the bash shell. Using a test switch (like -x for executiable) mixed with an && or ||. Example: [-x /usr/bin/firefox ] || exit I think it's very clear, to old hands, but not so much for a new or intermediate users. It certainly is the 'cleaner' form. Like the C styl

Re: Style question for conditional execution

On Nov 24, 2010, at 1:46 PM, Gerald Britton wrote: > Say that I have some function "f" that I will execute if some variable > "v" evaluates true. Using a classical procedural approach, I might > write: > >if v: >f() > > I might, however, think more in a functional-programming direct

Re: Style question for conditional execution

On Nov 24, 11:46 am, Gerald Britton wrote: > Say that I have some function "f" that I will execute if some variable > "v" evaluates true.  Using a classical procedural approach, I might > write: > >     if v: >         f() > > I might, however, think more in a functional-programming direction. > T

Style question for conditional execution

Writing in Python gives me the luxury of choosing different paradigms for similar operations. Lately I've been thinking about a minor detail that peaked my interest and am curious what others think: Say that I have some function "f" that I will execute if some variable "v" evaluates true. Using

RE: Style question - defining immutable class data members

I said: >> > My intent was to fix an obvious omission: a special case >> was discussed in >> > the "Augmented assignment statements" section, but an >> almost-identical >> > special case was omitted from the "Assignment statements" section. After finally getting registered at bugs.python.o

Re: Style question - defining immutable class data members

John Posner wrote: > [snip] > >> > If the object is a class instance and the attribute reference > occurs > >> > on both sides of the assignment operator; for example:: > >> > > >> > self.x = self.x + 1 > >> > > >> > ... in the RHS expression, ``self.x`` is evaluated with

RE: Style question - defining immutable class data members

[snip] >> > If the object is a class instance and the attribute reference occurs >> > on both sides of the assignment operator; for example:: >> > >> > self.x = self.x + 1 >> > >> > ... in the RHS expression, ``self.x`` is evaluated with >> > ``getattr()``, which ca

Re: Style question - defining immutable class data members

John Posner wrote: > On Mon Mar 16 03:42:42, I said: > >> RTFM, in section "Augmented assignment statements" of python301.chm: >> >> --- >> For targets which are attribute references, the initial value is retrieved > >> with a getattr() and the result is assigned with a setattr(). Notice that > t

Re: Style question - defining immutable class data members

On Mon Mar 16 03:42:42, I said: > RTFM, in section "Augmented assignment statements" of python301.chm: > > --- > For targets which are attribute references, the initial value is retrieved > with a getattr() and the result is assigned with a setattr(). Notice that the > two methods do not necess

Re: Style question - defining immutable class data members

In article , Maxim Khitrov wrote: > >Very simple question on the preferred coding style. I frequently write >classes that have some data members initialized to immutable values. >For example: > >class Test(object): >def __init__(self): >self.some_value = 0 >self.another_value

Re: Style question - defining immutable class data members

On Mon, 16 Mar 2009 09:31:59 -, Aaron Brady wrote: [snippety snip] Otherwise, either /1, every instance has its own entries for class functions, and subsequent changes to the class don't affect existing instances, or /2, every method call is of the form x.__class__.foo ( ). They're both b

Re: Style question - defining immutable class data members

On Mar 15, 9:54 pm, "Rhodri James" wrote: > On Sun, 15 Mar 2009 23:26:04 -, Aaron Brady   > wrote: > > > > > > > On Mar 15, 1:50 pm, "Rhodri James" > > wrote: > >> On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady   > >> wrote: > > >> > On Mar 15, 12:39 pm, John Posner wrote: > >> >> (My apo

Re: Style question - defining immutable class data members

John Posner wrote: Matthew Woodcraft said: I doubt it's because anyone particularly wanted this behaviour; it just falls out of the way '+=' is defined. At the point where 'inst.x += 1' is compiled, Python doesn't know whether 'inst.x' is going to turn out to be a class attribute or an inst

Re: Style question - defining immutable class data members

John Posner wrote: (My apologies if the thread has already covered this.) I believe I understand the WHAT in this situation, but I don't understand the WHY ... Given this class definition: class Cls(object): x = 345 ... I observe the following, using IDLE 2.6.1: inst = Cls() Cls.

Re: Style question - defining immutable class data members

On Mon, 2009-03-16 at 04:02 +, Tim Wintle wrote: > On Sun, 2009-03-15 at 10:39 -0700, John Posner wrote: Doh, reply out of thread there - I meant to reply to Rhodi's comment further down. > Is there any actual advantage to self.attribute picking up > Class.attribute instead of raising a NameEr

Re: Style question - defining immutable class data members

On Sun, 2009-03-15 at 10:39 -0700, John Posner wrote: > (My apologies if the thread has already covered this.) I believe I understand > the WHAT in this situation, but I don't understand the WHY ... > Is there a beneficial effect of silently creating the instance attribute, > which outweighs the

Re: Style question - defining immutable class data members

On Sun, 15 Mar 2009 23:26:04 -, Aaron Brady wrote: On Mar 15, 1:50 pm, "Rhodri James" wrote: On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady   wrote: > On Mar 15, 12:39 pm, John Posner wrote: >> (My apologies if the thread has already covered this.) I believe I   >> understand the WH

Re: Style question - defining immutable class data members

Earlier, I said: > I'll look into what the standard Python doc set says on this > matter. > RTFM, in section "Augmented assignment statements" of python301.chm: --- For targets which are attribute references, the initial value is retrieved with a getattr() and the result is assigned with a se

Re: Style question - defining immutable class data members

John Posner wrote: > Summary: I no longer suspect that "Python is broken". I *do* think that > there's a situation that is potentially quite confusing: > > * In the statement "self.x = self.x + 1", the two "self.x" names can > sometimes refer to different objects. But this is fundamental to Py

Re: Style question - defining immutable class data members

On Mar 15, 1:50 pm, "Rhodri James" wrote: > On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady   > wrote: > > > On Mar 15, 12:39 pm, John Posner wrote: > >> (My apologies if the thread has already covered this.) I believe I   > >> understand the WHAT in this situation, but I don't understand the WH

Re: Style question - defining immutable class data members

Matthew Woodcraft said: > I doubt it's because anyone particularly wanted this > behaviour; it just > falls out of the way '+=' is defined. > > At the point where 'inst.x += 1' is compiled, > Python doesn't know > whether 'inst.x' is going to turn out to be a class > attribute or an > instance a

Re: Style question - defining immutable class data members

M R A Barnett wrote: > Aaron Brady wrote: > [snip] > > However, in my (opined) interpretation, 'list.append(...) is an in- > > place operation' is a factual error. In-place operations -also- > > rebind their 'argument' (FLOBW for lack of better words). 'append' is > > a by-side-effect operation.

Re: Style question - defining immutable class data members

John Posner a écrit : (My apologies if the thread has already covered this.) I believe I understand the WHAT in this situation, but I don't understand the WHY ... Given this class definition: class Cls(object): x = 345 ... I observe the following, using IDLE 2.6.1: inst = Cls() Cls.x is inst

Re: Style question - defining immutable class data members

"Rhodri James" writes: > But do you, though? The only occasion I can think of that I'd want > the search to go past the instance is this "auto-initialisation", > and frankly I'd rather do that in an __init__ anyway. Perhaps > static methods or class methods work that way, I don't know how > the

Re: Style question - defining immutable class data members

Rhodri James a écrit : On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady wrote: On Mar 15, 12:39 pm, John Posner wrote: (snip) Is there a beneficial effect of silently creating the instance attribute, which outweighs the detrimental effects: (1) inconsistency, (2) the "surprising" decoupli

Re: Style question - defining immutable class data members

John Posner writes: > My question is ... WHY does the interpreter silently create the > instance attribute at this point, causing a "surprising decoupling" > from the class attribute? WHY doesn't the interpreter behave as it > would with a simple, non-instance variable: > > python > Python 2

Re: Style question - defining immutable class data members

On Sun, 15 Mar 2009 17:55:25 -, Aaron Brady wrote: On Mar 15, 12:39 pm, John Posner wrote: (My apologies if the thread has already covered this.) I believe I understand the WHAT in this situation, but I don't understand the WHY ... [snip] My question is ... WHY does the interprete

Re: Style question - defining immutable class data members

On Mar 15, 12:39 pm, John Posner wrote: > (My apologies if the thread has already covered this.) I believe I understand > the WHAT in this situation, but I don't understand the WHY ... > > Given this class definition: > >   class Cls(object): >       x = 345 > > ... I observe the following, using

Re: Style question - defining immutable class data members

(My apologies if the thread has already covered this.) I believe I understand the WHAT in this situation, but I don't understand the WHY ... Given this class definition: class Cls(object): x = 345 ... I observe the following, using IDLE 2.6.1: >>> inst = Cls() >>> Cls.x is inst.x True

Re: Style question - defining immutable class data members

Aaron Brady wrote: [snip] However, in my (opined) interpretation, 'list.append(...) is an in- place operation' is a factual error. In-place operations -also- rebind their 'argument' (FLOBW for lack of better words). 'append' is a by-side-effect operation. However colloquially it's mostly accur

Re: Style question - defining immutable class data members

On Mar 15, 8:56 am, "Rhodri James" wrote: > On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft   > > wrote: > > [snip Gary Herron's explanation of instance attribute lookup > falling back to class attribute lookup] > > > It seems clear to me that Maxim understood all this when he asked his > >

Re: Style question - defining immutable class data members

Maxim Khitrov a écrit : On Sat, Mar 14, 2009 at 2:07 PM, Gary Herron wrote: Maxim Khitrov wrote: Very simple question on the preferred coding style. I frequently write classes that have some data members initialized to immutable values. For example: class Test(object): def __init__(self):

Re: Style question - defining immutable class data members

On Sun, 15 Mar 2009 15:05:04 -, Matthew Woodcraft wrote: "Rhodri James" writes: On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft It seems clear to me that Maxim understood all this when he asked his original question (you need to understand this subtlety to know why the trick h

Re: Style question - defining immutable class data members

"Rhodri James" writes: > On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft >> It seems clear to me that Maxim understood all this when he asked his >> original question (you need to understand this subtlety to know why >> the trick he was asking about only works for immutable values). > > It

Re: Style question - defining immutable class data members

On Sun, 15 Mar 2009 13:26:17 -, Matthew Woodcraft wrote: [snip Gary Herron's explanation of instance attribute lookup falling back to class attribute lookup] It seems clear to me that Maxim understood all this when he asked his original question (you need to understand this subtlety to k

Re: Style question - defining immutable class data members

Gary Herron writes: > Gary Herron wrote: > No, you are still misinterpreting your results. But you can be forgiven > because this is quite a subtle point about Python's attribute access. > > Here's how it works: > > On access, self.count (or self.anything) attempts to find "count" in > the inst

Re: Style question - defining immutable class data members

Maxim Khitrov wrote: On Sat, Mar 14, 2009 at 5:38 PM, Matthew Woodcraft wrote: Gary Herron writes: I think this code is in poor taste: it's clear that it will confuse people (which is what Maxim was asking about in the first place). Careful now -- I didn't write that. (Although I ag

Re: Style question - defining immutable class data members

Maxim Khitrov wrote: On Sat, Mar 14, 2009 at 4:31 PM, Gary Herron wrote: Perhaps a different example would help explain what I'm trying to do: class Case1(object): def __init__(self): self.count = 0 self.list = [] def inc(self): s

Re: Style question - defining immutable class data members

Hallöchen! Maxim Khitrov writes: > [...] > > The advantage of doing this is that the assignments are evaluated > once and thus the creation of that class is a bit faster. Access > is still performed through self.some_value and > self.another_value. Is there a reason to prefer the first style > ov

Re: Style question - defining immutable class data members

On Sat, Mar 14, 2009 at 5:38 PM, Matthew Woodcraft wrote: > Gary Herron writes: > I think this code is in poor taste: it's clear that it will confuse > people (which is what Maxim was asking about in the first place). Yes, I see that now, thanks :) - Max -- http://mail.python.org/mailman/listin

Re: Style question - defining immutable class data members

On Sat, Mar 14, 2009 at 4:31 PM, Gary Herron wrote: >> Perhaps a different example would help explain what I'm trying to do: >> >> class Case1(object): >>        def __init__(self): >>                self.count = 0 >>                self.list  = [] >> >>        def inc(self): >>                sel

Re: Style question - defining immutable class data members

Gary Herron writes: > But now you are not listening to what people are telling you. It has > *nothing* to do with the mutability/immutability of the integer and the list > your two classes create. No! Did you run the code he posted? The immutability makes all the difference. > The difference

Re: Style question - defining immutable class data members

Maxim Khitrov wrote: Perhaps a different example would help explain what I'm trying to do: class Case1(object): def __init__(self): self.count = 0 self.list = [] def inc(self): self.count += 1 self.list.append(sel

Re: Style question - defining immutable class data members

Maxim Khitrov wrote: On Sat, Mar 14, 2009 at 2:07 PM, Gary Herron wrote: Maxim Khitrov wrote: Very simple question on the preferred coding style. I frequently write classes that have some data members initialized to immutable values. For example: class Test(object): def __init__(se

Re: Style question - defining immutable class data members

On Sat, Mar 14, 2009 at 12:32 PM, Maxim Khitrov wrote: > Very simple question on the preferred coding style. I frequently write > classes that have some data members initialized to immutable values. > For example: > > class Test(object): >    def __init__(self): >        self.some_value = 0 >    

Re: Style question - defining immutable class data members

On Sat, Mar 14, 2009 at 2:07 PM, Gary Herron wrote: > Maxim Khitrov wrote: >> >> Very simple question on the preferred coding style. I frequently write >> classes that have some data members initialized to immutable values. >> For example: >> >> class Test(object): >>    def __init__(self): >>    

Re: Style question - defining immutable class data members

Maxim Khitrov wrote: On Sat, Mar 14, 2009 at 12:50 PM, MRAB wrote: Maxim Khitrov wrote: Very simple question on the preferred coding style. I frequently write classes that have some data members initialized to immutable values. For example: class Test(object): def __init__(self): se

Re: Style question - defining immutable class data members

Maxim Khitrov wrote: Very simple question on the preferred coding style. I frequently write classes that have some data members initialized to immutable values. For example: class Test(object): def __init__(self): self.some_value = 0 self.another_value = None Similar effect

Re: Style question - defining immutable class data members

Maxim Khitrov: > When the types are immutable, there is no difference. But you may want different instances to have different immutable data. Generally if the data (immutable or not) is the same for all the instances, use class attributes, otherwise use instance attributes. Bye, bearophile -- ht

Re: Style question - defining immutable class data members

On Sat, Mar 14, 2009 at 12:50 PM, MRAB wrote: > Maxim Khitrov wrote: >> >> Very simple question on the preferred coding style. I frequently write >> classes that have some data members initialized to immutable values. >> For example: >> >> class Test(object): >>    def __init__(self): >>        se

Re: Style question - defining immutable class data members

Maxim Khitrov wrote: Very simple question on the preferred coding style. I frequently write classes that have some data members initialized to immutable values. For example: class Test(object): def __init__(self): self.some_value = 0 self.another_value = None Similar effect

Style question - defining immutable class data members

Very simple question on the preferred coding style. I frequently write classes that have some data members initialized to immutable values. For example: class Test(object): def __init__(self): self.some_value = 0 self.another_value = None Similar effect can be achieved by defi

Re: Python Style Question

Steve Holden wrote: K-Dawg wrote: I am trying to become more pythonic as I learn python and get my mind around it instead of other languages I have used. I have an app that has a series of classes for objects it uses. From a style perspective, which should be done: Different py file for each

Re: Python Style Question

K-Dawg wrote: > I am trying to become more pythonic as I learn python and get my mind > around it instead of other languages I have used. > > I have an app that has a series of classes for objects it uses. From a > style perspective, which should be done: > > Different py file for each class >

Python Style Question

I am trying to become more pythonic as I learn python and get my mind around it instead of other languages I have used. I have an app that has a series of classes for objects it uses. From a style perspective, which should be done: Different py file for each class or One py file with all the c

Re: style question - hasattr

On Tue, Apr 8, 2008 at 10:21 PM, ian <[EMAIL PROTECTED]> wrote: > Ok, so what about 'hasattr' ?? > hasattr(myObject,'property') > seems equivalent to > 'property' in dir(myObject) > > I would suggest that using the 'in' is cleaner in this case also. Is > there a performance penalty her

Re: style question - hasattr

"ian" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | In old python code i would use 'has_key' to determine if an element | was present in a dictionary. | | Python 3.0 will even removed 'has_key'. The reason for removal is that | using the 'in' operator is a cleaner syntax and havin

style question - hasattr

In old python code i would use 'has_key' to determine if an element was present in a dictionary. Python 3.0 will even removed 'has_key'. The reason for removal is that using the 'in' operator is a cleaner syntax and having two ways to achieve the same result is against the principle of the languag

Re: docstrings style question

On Fri, 11 Jan 2008 13:09:26 +1100, Steve Brown wrote: > What I'm trying to do with the tests is pare them back so that the code > explicitly and concisely documents the tests. Yes, this is good. > It is important that the comments and doc strings NOT contain > information about how Temperature

Re: docstrings style question

What I'm trying to do with the tests is pare them back so that the code explicitly and concisely documents the tests. It is important that the comments and doc strings NOT contain information about how Temperature Sense works because that is outside the scope of the test. More generally, comments

Re: docstrings style question

"Neil Cerutti" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Jan 10, 2008 12:47 AM, Steve Brown <[EMAIL PROTECTED]> wrote: >> I've got a series of modules which look like this: >> >> # >> # >> # Temperature Sense Test >> # >> # >> class Test3(ar_test.AR_

Re: docstrings style question

On Jan 10, 2008 12:47 AM, Steve Brown <[EMAIL PROTECTED]> wrote: > I've got a series of modules which look like this: > > # > # > # Temperature Sense Test > # > # > class Test3(ar_test.AR_TEST): > """Temperature Sense Test""" > > > I don't like the duplicated information

Re: docstrings style question

"Russ P." <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Jan 9, 11:51 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote: >> Steve Brown wrote: >> > I've got a series of modules which look like this: >> >> > # >> > # >> > # Temperature Sense Test >> > # >> > # >

Re: docstrings style question

Russ P. wrote: > On Jan 9, 9:47 pm, "Steve Brown" <[EMAIL PROTECTED]> wrote: >> I've got a series of modules which look like this: >> >> # >> # >> # Temperature Sense Test >> # >> # >> class Test3(ar_test.AR_TEST): >> """Temperature Sense Test""" >> >> I don't like the

RE: docstrings style question

> On Behalf Of Steve Brown > What do you think? I think that comments are for maintainers, and docstrings are for users. Some of the things I use comments for: * Visually separate classes (using a syntax-highlighting editor) * Explain algorithm choices * Explain bug fixes so I don't later "fix"

Re: docstrings style question

-On [20080110 06:51], Steve Brown ([EMAIL PROTECTED]) wrote: >I don't like the duplicated information: But the comment is attractive, I find it unattractive to be honest. >and the docstring self.__doc__ is already in use in the test log. I've read >that all modules and classes should have docstri

Re: docstrings style question

On Jan 9, 11:51 pm, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Steve Brown wrote: > > I've got a series of modules which look like this: > > > # > > # > > # Temperature Sense Test > > # > > # > > class Test3(ar_test.AR_TEST): > > """Temperature Sense Test""" > > > I don'

Re: docstrings style question

Steve Brown wrote: > I've got a series of modules which look like this: > > # > # > # Temperature Sense Test > # > # > class Test3(ar_test.AR_TEST): > """Temperature Sense Test""" > > > I don't like the duplicated information: But the comment is attractive, and > th

Re: docstrings style question

On Jan 9, 9:47 pm, "Steve Brown" <[EMAIL PROTECTED]> wrote: > I've got a series of modules which look like this: > > # > # > # Temperature Sense Test > # > # > class Test3(ar_test.AR_TEST): > """Temperature Sense Test""" > > I don't like the duplicated information: But t

docstrings style question

I've got a series of modules which look like this: # # # Temperature Sense Test # # class Test3(ar_test.AR_TEST): """Temperature Sense Test""" I don't like the duplicated information: But the comment is attractive, and the docstring self.__doc__ is already in use in

Re: style question

Hari Sekhon wrote: > Is it better to do: > message = """This is line1. This is line2 This is line3\n""" > > or > > message = "This is line1.\n message = message + "This is line2\n" > message = message + "This is line3\n" > > Since the first method does not follow python's clean and easy > lo

Re: Non-ASCII languages (was: Re: style question)

In article <[EMAIL PROTECTED]>, Jorgen Grahn <[EMAIL PROTECTED]> writes: |> |> Possibly true, and definitely for Knuth. But WYSIWYG was unknown at the |> time; these people all programmed using fixed-width fonts, on teletypes or |> character-mapped terminals. Hell, even full-screen editors were

Non-ASCII languages (was: Re: style question)

On Thu, 29 Jun 2006 23:19:34 +0200, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Jorgen Grahn wrote: ... >> (I like well-typeset code in print though. Bjarne Stroustrup uses an elegant >> system for C++ code, where identifiers and strings are in Times italic, >> operators in Courier, and so on.) > >

Re: style question

On Thu, 29 Jun 2006 23:19:34 +0200, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Jorgen Grahn wrote: > >>> assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable >>> indentation >>> no matter what font you're using, you can write [...] >> >> Since when? I've always coded, in all l

Re: style question

On Thu, 29 Jun 2006 15:31:53 -0700, Scott David Daniels <[EMAIL PROTECTED]> wrote: ... >> I like well-typeset code in print though. Bjarne Stroustrup uses an elegant >> system for C++ code, > See Knuth on Literate Programming and the "Web" systems (e.g. CWeb). > His goal is to look good type

Re: style question

Jorgen Grahn wrote: > On Mon, 26 Jun 2006 11:47:21 +0200, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > ... >> assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable >> indentation >> no matter what font you're using, you can write [...] > > Since when? I've always coded, in all la

Re: style question

Jorgen Grahn wrote: >> assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable >> indentation >> no matter what font you're using, you can write [...] > > Since when? I've always coded, in all languages I've ever used[1], under the > assumption that the reader will view it with

Re: style question

On Mon, 26 Jun 2006 11:47:21 +0200, Fredrik Lundh <[EMAIL PROTECTED]> wrote: ... > assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable > indentation > no matter what font you're using, you can write [...] Since when? I've always coded, in all languages I've ever used[1], unde

Re: style question

Claudio Grondi wrote: > Hari Sekhon wrote: >> On 26/06/06, *Claudio Grondi* <[EMAIL PROTECTED] >> > wrote: >> >> Scott David Daniels wrote: >> > Claudio Grondi wrote: >> > <<>> >> > >> >> When necessary to skip first line _and_ indentation: >>

Re: style question

On 26/06/06, Claudio Grondi <[EMAIL PROTECTED]> wrote: Scott David Daniels wrote:> Claudio Grondi wrote:> <<> When necessary to skip first line _and_ indentation:>>   message = """ >>   This is line 1>>   This is line 2>>   This is line 3>>   """.replace('\n  ', '\n')[1:] # adjust here '\n  ' t

Re: style question

Scott David Daniels wrote: > Claudio Grondi wrote: > <<>> > >> When necessary to skip first line _and_ indentation: >> message = """ >> This is line 1 >> This is line 2 >> This is line 3 >> """.replace('\n ', '\n')[1:] # adjust here '\n ' to indentation > > > Riffing on this idea: >

Re: style question

Claudio Grondi wrote: <<>> > When necessary to skip first line _and_ indentation: > message = """ > This is line 1 > This is line 2 > This is line 3 > """.replace('\n ', '\n')[1:] # adjust here '\n ' to indentation Riffing on this idea: message = """ This is line 1

<    1   2   3   >