Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #78863 > unrolled thread

Toggle

Back to article view | Back to comp.lang.python

Contents

  Toggle Seymore4Head <Seymore4Head@Hotmail.invalid> - 2014-10-08 20:11 -0400
    Re: Toggle Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-09 12:29 +1100
      [OT] spelling colour / color was Re: Toggle mm0fmf <none@mailinator.com> - 2014-10-09 18:43 +0100
        Re: [OT] spelling colour / color was Re: Toggle duncan smith <buzzard@invalid.invalid> - 2014-10-09 19:24 +0100
          Re: [OT] spelling colour / color was Re: Toggle Tim Delaney <timothy.c.delaney@gmail.com> - 2014-10-10 06:53 +1100
            Re: [OT] spelling colour / color was Re: Toggle Marko Rauhamaa <marko@pacujo.net> - 2014-10-09 23:48 +0300
              Re: [OT] spelling colour / color was Re: Toggle alister <alister.nospam.ware@ntlworld.com> - 2014-10-10 17:31 +0000
                Re: [OT] spelling colour / color was Re: Toggle Marko Rauhamaa <marko@pacujo.net> - 2014-10-10 22:01 +0300
                  Re: [OT] spelling colour / color was Re: Toggle alister <alister.nospam.ware@ntlworld.com> - 2014-10-10 20:05 +0000
                    Re: [OT] spelling colour / color was Re: Toggle Christian Gollwitzer <auriocus@gmx.de> - 2014-10-11 11:37 +0200
                      Re: [OT] spelling colour / color was Re: Toggle mm0fmf <none@mailinator.com> - 2014-10-11 12:45 +0100
                        Re: [OT] spelling colour / color was Re: Toggle duncan smith <buzzard@invalid.invalid> - 2014-10-11 16:26 +0100
                          Re: [OT] spelling colour / color was Re: Toggle Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-10-11 15:20 -0400
                          Re: [OT] spelling colour / color was Re: Toggle William Ray Wing <wrw@mac.com> - 2014-10-11 15:55 -0400
                            Re: [OT] spelling colour / color was Re: Toggle duncan smith <buzzard@invalid.invalid> - 2014-10-12 00:40 +0100
                              Re: [OT] spelling colour / color was Re: Toggle giacomo boffi <pecore@pascolo.net> - 2014-10-18 09:06 +0200
                      Re: [OT] spelling colour / color was Re: Toggle Simon Ward <simon+python@bleah.co.uk> - 2014-10-11 15:45 +0100
          Re: [OT] spelling colour / color was Re: Toggle "Neil D. Cerutti" <neilc@norwich.edu> - 2014-10-10 10:46 -0400
          Re: [OT] spelling colour / color was Re: Toggle Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-10 18:45 +0100
        Re: [OT] spelling colour / color was Re: Toggle Terry Reedy <tjreedy@udel.edu> - 2014-10-09 18:53 -0400
          Re: [OT] spelling colour / color was Re: Toggle Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-10 18:11 +1100
            Re: [OT] spelling colour / color was Re: Toggle Marko Rauhamaa <marko@pacujo.net> - 2014-10-10 13:08 +0300
              Re: [OT] spelling colour / color was Re: Toggle Chris Angelico <rosuav@gmail.com> - 2014-10-10 21:40 +1100
                Re: [OT] spelling colour / color was Re: Toggle Marko Rauhamaa <marko@pacujo.net> - 2014-10-10 13:51 +0300
                  Re: [OT] spelling colour / color was Re: Toggle Chris Angelico <rosuav@gmail.com> - 2014-10-10 22:50 +1100
                  Re: [OT] spelling colour / color was Re: Toggle Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-10-10 20:19 -0400
                    Re: [OT] spelling colour / color was Re: Toggle Marko Rauhamaa <marko@pacujo.net> - 2014-10-11 13:33 +0300
                      Re: [OT] spelling colour / color was Re: Toggle Chris Angelico <rosuav@gmail.com> - 2014-10-11 22:03 +1100
        Re: [OT] spelling colour / color was Re: Toggle Chris Angelico <rosuav@gmail.com> - 2014-10-10 10:21 +1100
        Re: [OT] spelling colour / color was Re: Toggle Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-10 17:52 +1100
          Re: [OT] spelling colour / color was Re: Toggle Chris Angelico <rosuav@gmail.com> - 2014-10-10 18:04 +1100
        Re: [OT] spelling colour / color was Re: Toggle Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-10 18:38 +0100
    Re: Toggle Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-09 02:25 +0100
    Re:Toggle Dave Angel <davea@davea.name> - 2014-10-08 21:24 -0400
    Re: Toggle Ben Finney <ben+python@benfinney.id.au> - 2014-10-09 12:42 +1100
      Re: Toggle Rustom Mody <rustompmody@gmail.com> - 2014-10-08 19:34 -0700
        Re: Toggle Steven D'Aprano <steve@pearwood.info> - 2014-10-09 04:56 +0000
          Re: Toggle Rustom Mody <rustompmody@gmail.com> - 2014-10-08 22:39 -0700
            Re: Toggle Chris Angelico <rosuav@gmail.com> - 2014-10-09 16:55 +1100
            Re: Toggle Peter Otten <__peter__@web.de> - 2014-10-09 09:51 +0200
              Re: Toggle Rustom Mody <rustompmody@gmail.com> - 2014-10-09 05:42 -0700
                Re: Toggle Terry Reedy <tjreedy@udel.edu> - 2014-10-09 16:57 -0400
            Re: Toggle Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-10 18:18 +1100
              Re: Toggle Rustom Mody <rustompmody@gmail.com> - 2014-10-10 07:24 -0700
                Re: Toggle Rustom Mody <rustompmody@gmail.com> - 2014-10-10 07:28 -0700
                  Re: Toggle Chris Angelico <rosuav@gmail.com> - 2014-10-11 01:36 +1100
        Re: Toggle Ian Kelly <ian.g.kelly@gmail.com> - 2014-10-09 10:07 -0600
          Re: Toggle Rustom Mody <rustompmody@gmail.com> - 2014-10-09 09:33 -0700
            Re: Toggle Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-10 18:15 +1100
    Re: Toggle Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-09 04:02 +0100
    Re: Toggle random832@fastmail.us - 2014-10-08 23:54 -0400
    Re: Toggle Chris Angelico <rosuav@gmail.com> - 2014-10-09 14:57 +1100
    Re: Toggle Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-10-09 17:57 +1300
      Re: Toggle Travis Griggs <travisgriggs@gmail.com> - 2014-10-08 22:38 -0700
      Re: Toggle alister <alister.nospam.ware@ntlworld.com> - 2014-10-09 15:23 +0000
        Re: Toggle Tony the Tiger <tony@tiger.invalid> - 2014-10-12 18:38 +0000
          Re: Toggle Chris Angelico <rosuav@gmail.com> - 2014-10-13 05:43 +1100
            Re: Toggle alister <alister.nospam.ware@ntlworld.com> - 2014-10-13 08:09 +0000
    Re: Toggle Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-10-10 13:44 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#78886

On Thursday, October 9, 2014 1:21:49 PM UTC+5:30, Peter Otten wrote:
> Rustom Mody wrote:
> > BTW is there some flag that can make them identical?

> No flag, but you can tweak that P:

> >>> import sys
> >>> sys.displayhook = print
> >>> "foo"
> foo
> >>> def f(): pass
> ... 
> >>> f()
> None

Yeah. Thats what I was looking for -- thanks!

With print as above:

>>> "Hello World\n"
Hello World

>>>



With default displayhook:

>>> "Hello World\n"
'Hello World\n'
>>>

[toc] | [prev] | [next] | [standalone]

#78912

On 10/9/2014 8:42 AM, Rustom Mody wrote:
> On Thursday, October 9, 2014 1:21:49 PM UTC+5:30, Peter Otten wrote:
>> Rustom Mody wrote:
>>> BTW is there some flag that can make them identical?
>
>> No flag, but you can tweak that P:
>
>>>>> import sys
>>>>> sys.displayhook = print
>>>>> "foo"
>> foo
>>>>> def f(): pass
>> ...
>>>>> f()
>> None
>
> Yeah. Thats what I was looking for -- thanks!
>
> With print as above:
>
>>>> "Hello World\n"
> Hello World

> With default displayhook:
>
>>>> "Hello World\n"
> 'Hello World\n'

For anyone wondering, the reason for the default behavior is to avoid 
ambiguity between ints and strings containing digits.

 >>> print(123)
123
 >>> print('123')
123
 >>> '123'
'123'

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#78932

Rustom Mody wrote:

> On Thursday, October 9, 2014 10:26:41 AM UTC+5:30, Steven D'Aprano wrote:
>> On Wed, 08 Oct 2014 19:34:30 -0700, Rustom Mody wrote:
> 
>> >>>> Color.Red
>> >>>> print (Color.Red)
>> > Color.Red
>> > # Not sure what to make of that distinction...
> 
>> That's because the interactive interpreter displays the repr() of objects
>> (except for None, which it suppresses), while print outputs the str() of
>> them.
> 
> Yeah...
> 
> What I meant to wonder upon was: "Is this behavior what the pro-print or
> the anti-print folks like?"

Python's print is a tool, not a political party or religion. I'm no
more "pro-print" than I'm "pro-len" and "anti-float". I use it when
appropriate, and don't use it when it isn't.


> In any case that the P in REPL is not *exactly* the same as print

The "P" in Read Eval Print Loop no more stands for Python's print function
(or statement, in 2.x) than the "R" stands for Perl's read(), the "E" for
Lisp's eval, or the L for, um, whatever concrete example of a function
called "loop" we can come up with. It's a generic term that describes the
actions of the interactive environment, not the specific semantics used.


> (or equivalently the distinction between str and repr) makes for some
> intricate noob confusions.

I've been reading this mailing list / newsgroup, and the tutor mailing list,
for over a decade, and I don't recall ever seeing a newbie confused by the
difference between str() and repr(), or why print uses one and the
interactive interpreter the other. I've seen the odd question about it, but
I wouldn't call it "confused". 

That's not to say that it categorically never happened. I'm sure that
*somewhere* there is somebody who is confused. There probably is one or two
newbies out there who lie awake at night wondering why the output of print
looks different from the output in the interactive interpreter. But I do
not believe that this is a widespread problem.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#78951

On Friday, October 10, 2014 12:48:20 PM UTC+5:30, Steven D'Aprano wrote:
> Rustom Mody wrote:

> > On Thursday, October 9, 2014 10:26:41 AM UTC+5:30, Steven D'Aprano wrote:
> >> On Wed, 08 Oct 2014 19:34:30 -0700, Rustom Mody wrote:
> >> >>>> Color.Red
> >> >>>> print (Color.Red)
> >> > Color.Red
> >> > # Not sure what to make of that distinction...
> >> That's because the interactive interpreter displays the repr() of objects
> >> (except for None, which it suppresses), while print outputs the str() of
> >> them.
> > Yeah...
> > What I meant to wonder upon was: "Is this behavior what the pro-print or
> > the anti-print folks like?"

> Python's print is a tool, not a political party or religion. I'm no
> more "pro-print" than I'm "pro-len" and "anti-float". I use it when
> appropriate, and don't use it when it isn't.

Yeah... in an ideal world politics and science/technology would be separable
if not completely separate. I dont see such a world (round me at least).

See (particularly section 2):
http://blog.jot.fm/2010/08/26/ten-things-i-hate-about-object-oriented-programming/comment-page-2/

> > In any case that the P in REPL is not *exactly* the same as print

> The "P" in Read Eval Print Loop no more stands for Python's print function
> (or statement, in 2.x) than the "R" stands for Perl's read(), the "E" for
> Lisp's eval, or the L for, um, whatever concrete example of a function
> called "loop" we can come up with. It's a generic term that describes the
> actions of the interactive environment, not the specific semantics used.

> > (or equivalently the distinction between str and repr) makes for some
> > intricate noob confusions.

> That's not to say that it categorically never happened. I'm sure that
> *somewhere* there is somebody who is confused. There probably is one or two
> newbies out there who lie awake at night wondering why the output of print
> looks different from the output in the interactive interpreter. But I do
> not believe that this is a widespread problem.


I think Ive seen a number of confusions on this list from the fact 
that None quietly disappears at REPL top level and no where else.
Yeah this is no str vs repr but print statement/expression vs REPL-print.

> I've been reading this mailing list / newsgroup, and the tutor mailing list,
> for over a decade, and I don't recall ever seeing a newbie confused by the
> difference between str() and repr(), or why print uses one and the
> interactive interpreter the other. I've seen the odd question about it, but
> I wouldn't call it "confused". 

Count me as noob then!
http://stackoverflow.com/questions/1436703/difference-between-str-and-repr-in-python
are some explanations:

Alex Martelli:
repr -- should be unambiguous
str -- should be human readable

Ned Batchelder:
repr for developers
str for customers

More telling comments from Alex (same SO post)
1. Both have mostly useless default implementations
2. if you override __repr__, that's ALSO used for __str__, but not vice versa
3. despite the words on the subject found in typical docs, hardly
   anybody bothers making the __repr__ of objects be a string that
   eval may use to build an equal object (it's just too hard, AND not
   knowing how the relevant module was actually imported makes it
   actually flat out impossible).

If you dont find all this confusing, I am reminded of Schrödinger (or
one of his ilk):

If you dont find Quantum physics confusing you've not begun to understand it

For myself: Yeah I understand the philosophy (vaguely)
Exact detailed differences -- I never remember.
In particular when which is called.
Also which defaults to the other.

In any case when teaching beginners, I dont want to have anything to
do with repr. Just as a teacher of school arithmetic does not
generalize arithmetic to Rings and Fields

[toc] | [prev] | [next] | [standalone]

#78952

On Friday, October 10, 2014 7:54:33 PM UTC+5:30, Rustom Mody wrote:
> More telling comments from Alex (same SO post)
> 1. Both have mostly useless default implementations
> 2. if you override __repr__, that's ALSO used for __str__, but not vice versa
> 3. despite the words on the subject found in typical docs, hardly
>    anybody bothers making the __repr__ of objects be a string that
>    eval may use to build an equal object (it's just too hard, AND not
>    knowing how the relevant module was actually imported makes it
>    actually flat out impossible).

> If you dont find all this confusing, I am reminded of Schrödinger (or
> one of his ilk):

> If you dont find Quantum physics confusing you've not begun to understand it

Ok: Not Schrödinger but John Wheeler:
http://www.colorado.edu/physics/phys3220/phys3220_fa08/quotes.html

[toc] | [prev] | [next] | [standalone]

#78953

On Sat, Oct 11, 2014 at 1:28 AM, Rustom Mody <rustompmody@gmail.com> wrote:
>> If you dont find all this confusing, I am reminded of Schrödinger (or
>> one of his ilk):
>
>> If you dont find Quantum physics confusing you've not begun to understand it
>
> Ok: Not Schrödinger but John Wheeler:
> http://www.colorado.edu/physics/phys3220/phys3220_fa08/quotes.html

Schroedinger's quote. It's both correctly and incorrectly attributed,
until someone actually goes and looks it up, at which point its
waveform collapses.

ChrisA

[toc] | [prev] | [next] | [standalone]

#78901

On Wed, Oct 8, 2014 at 8:34 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Thursday, October 9, 2014 7:12:41 AM UTC+5:30, Ben Finney wrote:
>> Seymore4Head writes:
>
>> > I want to toggle between color="Red" and color="Blue"
>
>> It's good to cultivate ongoing familiarity with the standard library
>
> And language. In recent python3:
>
>>>> class Color(Enum):
> ...   Red = 0
> ...   Blue = 1
> ...
>>>> Color.Red
> <Color.Red: 0>
>>>> print (Color.Red)
> Color.Red
>
> # Not sure what to make of that distinction...
>
>>>> c=Color.Red
>>>> c = Color.Blue if c==Color.Red else Color.Red
>>>> c
> <Color.Blue: 1>
>>>>
>
>>>> # Better
>>>> def toggle(c): return Color.Blue if c==Color.Red else Color.Red
> ...
>>>> toggle(c)
> <Color.Blue: 1>
>>>> toggle(c)
> <Color.Blue: 1>
>
> # which means the c has not changed

Python enums can have methods and properties, which means that toggle
could be implemented as such:

>>> class Color(Enum):
...   red = 0
...   blue = 1
...   def toggle(self):
...     return Color.blue if self is Color.red else Color.red
...
>>> Color.blue.toggle()
<Color.red: 0>
>>> Color.blue.toggle().toggle()
<Color.blue: 1>

(Note the recommended way to compare enum instances is with "is", not "==".)

[toc] | [prev] | [next] | [standalone]

#78904

On Thursday, October 9, 2014 9:39:07 PM UTC+5:30, Ian wrote:
> On Wed, Oct 8, 2014 at 8:34 PM, Rustom Mody wrote:
> > On Thursday, October 9, 2014 7:12:41 AM UTC+5:30, Ben Finney wrote:
> >> Seymore4Head writes:
> >> > I want to toggle between color="Red" and color="Blue"
> >> It's good to cultivate ongoing familiarity with the standard library
> > And language. In recent python3:
> >>>> class Color(Enum):
> > ...   Red = 0
> > ...   Blue = 1
> > ...
> >>>> Color.Red
> >>>> print (Color.Red)
> > Color.Red
> > # Not sure what to make of that distinction...
> >>>> c=Color.Red
> >>>> c = Color.Blue if c==Color.Red else Color.Red
> >>>> c
> >>>> # Better
> >>>> def toggle(c): return Color.Blue if c==Color.Red else Color.Red
> > ...
> >>>> toggle(c)
> >>>> toggle(c)
> > # which means the c has not changed

> Python enums can have methods and properties, which means that toggle
> could be implemented as such:

> >>> class Color(Enum):
> ...   red = 0
> ...   blue = 1
> ...   def toggle(self):
> ...     return Color.blue if self is Color.red else Color.red
> ...
> >>> Color.blue.toggle()
> >>> Color.blue.toggle().toggle()

Nice!

In fact this:
> >>> Color.blue.toggle()
> <Color.red: 0>
> >>> Color.blue.toggle().toggle()
> <Color.blue: 1> 

is a nice example of a pattern that is rarely seen: 
OO syntax, functional (ie non-state-changing) semantics.


It would have been even nicer were this acceptable [Its not :-( ]

>>> class Color(Enum):
...   red = 0
...   blue = 1
...   def toggle(self):
...      return blue if self is red else red



> (Note the recommended way to compare enum instances is with "is", not "==".)

Umm... I know...

Im in Lent -- fasting off contentious territories.
[You may remember that I'd rather avoid 'is']

[toc] | [prev] | [next] | [standalone]

#78931

Rustom Mody wrote:

> In fact this:
>> >>> Color.blue.toggle()
>> <Color.red: 0>
>> >>> Color.blue.toggle().toggle()
>> <Color.blue: 1>
> 
> is a nice example of a pattern that is rarely seen:
> OO syntax, functional (ie non-state-changing) semantics.

You don't write much Python code, do you? *wink*

It is not "rarely seen" in Python:

some_string.strip().replace("x", "y").upper().split()

sort of thing is extremely common in Python.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#78870

On 09/10/2014 02:25, Mark Lawrence wrote:
> On 09/10/2014 01:11, Seymore4Head wrote:
>> I want to toggle between color="Red" and color="Blue"
>> Here is one:
>>      if color == "Red":
>>          color = "Blue"
>>      else:
>>          color = "Red"
>> Here is two:
>> if x = "True" color = "Red"
>> else:
>> color="Blue"
>> x= not x
>>
>> Others?
>>
>
> Here http://stackoverflow.com/questions/8381735/toggle-a-value-in-python
> but why couldn't you search in the first place?
>

When I first read this I was extremely jealous of the originator but 
having used it umpteen times I'm still extremely jealous of the 
originator!!!  Why doesn't my mind work like his? :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#78871

On Wed, Oct 8, 2014, at 23:02, Mark Lawrence wrote:
> When I first read this I was extremely jealous of the originator but 
> having used it umpteen times I'm still extremely jealous of the 
> originator!!!  Why doesn't my mind work like his? :)

You could also keep the ints in two variables and do a ^= b : b ^= a : a
^= b. Or use a, b = b, a. What I don't see in that answer is any
benchmarking support for his sweeping assertions of what is the fastest
version.

[toc] | [prev] | [next] | [standalone]

#78872

On Thu, Oct 9, 2014 at 2:54 PM,  <random832@fastmail.us> wrote:
> On Wed, Oct 8, 2014, at 23:02, Mark Lawrence wrote:
>> When I first read this I was extremely jealous of the originator but
>> having used it umpteen times I'm still extremely jealous of the
>> originator!!!  Why doesn't my mind work like his? :)
>
> You could also keep the ints in two variables and do a ^= b : b ^= a : a
> ^= b. Or use a, b = b, a. What I don't see in that answer is any
> benchmarking support for his sweeping assertions of what is the fastest
> version.

Possibly because it doesn't matter. Who cares how fast it is? All you
need to do is go from either of two states to the other. If the
performance of that has any impact whatsoever on your code, there's
something wrong with your design.

ChrisA

[toc] | [prev] | [next] | [standalone]

#78874

Seymore4Head wrote:
> I want to toggle between color="Red" and color="Blue"

toggle = {"Red": "Blue", "Blue": "Red"}
color = toggle[color]

[toc] | [prev] | [next] | [standalone]

#78875

On Oct 8, 2014, at 9:57 PM, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote:

> Seymore4Head wrote:
>> I want to toggle between color="Red" and color="Blue"


Don’t forget polymorphic dispatch…

class Red(object):
    def toggle(self):
        return Blue()

class Blue(object):
    def toggle(self):
        return Red()


Blue().toggle().toggle().toggle().toggle().toggle() :)

--
Travis Griggs
Objologist
"Some of them wanted to sell me snake oil and I'm not necessarily going to dismiss all of these, as I have never found a rusty snake." --Terry Pratchett

[toc] | [prev] | [next] | [standalone]

#78895

On Thu, 09 Oct 2014 17:57:03 +1300, Gregory Ewing wrote:

> Seymore4Head wrote:
>> I want to toggle between color="Red" and color="Blue"
> 
> toggle = {"Red": "Blue", "Blue": "Red"}
> color = toggle[color]

How about a simple

colour = 'red' if colour == 'blue' else 'blue'



-- 
The light at the end of the tunnel is the headlight of an approaching 
train.

[toc] | [prev] | [next] | [standalone]

#79014

On Thu, 09 Oct 2014 15:23:49 +0000, alister wrote:

>> toggle = {"Red": "Blue", "Blue": "Red"}
>> color = toggle[color]
> 
> How about a simple
> 
> colour = 'red' if colour == 'blue' else 'blue'

I call that a subtle bug that most likely will jump up and bite your 
behind when you least expect it.

Using a dictionary serves you two meals from a single duck: your desired 
feature and built-in error checking. It only accepts 'Red' or 'Blue' and 
nothing else, since you get a key error if you try.

With the if-else not so, since you can feed it 'yellow' and get a result. 
Whether that result is correct or not, well, I'm not so sure.

Yes, 'yellow' *is* a color, just not one of the valid ones in this 
implementation of a toggle between 'red' and 'blue'.


 /Grrr
-- 
          ___                  ___
 (\_--_/)  | _ ._    _|_|_  _   |o _  _ ._
 ( 9  9 )  |(_)| |\/  |_| |(/_  ||(_|(/_|
 stripes are forever - as overripe ferrets

[toc] | [prev] | [next] | [standalone]

#79015

On Mon, Oct 13, 2014 at 5:38 AM, Tony the Tiger <tony@tiger.invalid> wrote:
>> colour = 'red' if colour == 'blue' else 'blue'
>
> I call that a subtle bug that most likely will jump up and bite your
> behind when you least expect it.

More generally, I'd say that this is solving a (very) slightly
different problem: it's providing a "toggle with default" feature,
where the part after the else is the default. If you don't want a
default, that's a bug. I've known times when that default makes life a
lot easier, in which case it'd be a feature.

ChrisA

[toc] | [prev] | [next] | [standalone]

#79038

On Mon, 13 Oct 2014 05:43:10 +1100, Chris Angelico wrote:

> On Mon, Oct 13, 2014 at 5:38 AM, Tony the Tiger <tony@tiger.invalid>
> wrote:
>>> colour = 'red' if colour == 'blue' else 'blue'
>>
>> I call that a subtle bug that most likely will jump up and bite your
>> behind when you least expect it.
> 
> More generally, I'd say that this is solving a (very) slightly different
> problem: it's providing a "toggle with default" feature,
> where the part after the else is the default. If you don't want a
> default, that's a bug. I've known times when that default makes life a
> lot easier, in which case it'd be a feature.
> 
> ChrisA

if the value of colour is being set by user input & an incorrect value 
can be set the the error is in not validating user input and more complex 
solutions are definitely req.

If the value is being set within the program itself and colour gets set 
to an incorrect value the bug lies elsewhere in the program.

this looks like a simple requirement to alternate the colour of a GUI 
element so it is unlikely that incorrect values will be set.

sometimes it is easy to get carried away & overcomplicate a simple task, 
I tend to follow the "KISS" principle wherever possible 



-- 
40 isn't old.  If you're a tree.

[toc] | [prev] | [next] | [standalone]

#78946

Op 09-10-14 om 03:42 schreef Ben Finney:
> Seymore4Head <Seymore4Head@Hotmail.invalid> writes:
>
>> I want to toggle between color="Red" and color="Blue"
> It's good to cultivate ongoing familiarity with the standard library
> <URL:https://docs.python.org/3/library/itertools.html#itertools.cycle>
> so that you can make use of wheels already invented and maintained::
>
>     import itertools
>
>     colours = ["Red", "Blue"]
>     colour_cycle = itertools.cycle(colours)
>
>     next(colour_cycle)    # → "Red"
>     next(colour_cycle)    # → "Blue"
>     next(colour_cycle)    # → "Red"
>     next(colour_cycle)    # → "Blue"
>     next(colour_cycle)    # → "Red"
>
>     for colour in colour_cycle:
>         # … loops indefinitely
>         # with ‘colour’ bound to each value in turn …

I think this solution will become rather involved fast, when
you have multiple toggles.

-- 
Antoon Pardon

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python

csiph-web