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

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

(test) ? a:b

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

Contents

  (test) ? a:b "ast" <nomail@invalid.com> - 2014-10-22 10:29 +0200
    Re: (test) ? a:b buscacio@gmail.com - 2014-10-22 02:05 -0700
      Re: (test) ? a:b "ast" <nomail@invalid.com> - 2014-10-22 11:14 +0200
        Re: (test) ? a:b Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-22 12:45 +0100
          Re: (test) ? a:b "ast" <nomail@invalid.com> - 2014-10-27 09:01 +0100
        Re: (test) ? a:b Michael Torrie <torriem@gmail.com> - 2014-10-22 11:16 -0600
          Re: (test) ? a:b Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-23 11:44 +1100
      Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-22 20:15 +1100
      Re: (test) ? a:b Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-22 10:16 +0100
      Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-22 20:27 +1100
        Re: (test) ? a:b Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-10-23 16:46 +1300
          Re: (test) ? a:b MRAB <python@mrabarnett.plus.com> - 2014-10-23 11:12 +0100
            Re: (test) ? a:b "ast" <nomail@invalid.com> - 2014-10-24 08:38 +0200
          Re: (test) ? a:b Michael Torrie <torriem@gmail.com> - 2014-10-25 19:04 -0600
            Re: (test) ? a:b Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-10-27 22:04 +1300
          Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-26 12:20 +1100
          Re: (test) ? a:b Michael Torrie <torriem@gmail.com> - 2014-10-25 21:05 -0600
      Re: (test) ? a:b Ned Batchelder <ned@nedbatchelder.com> - 2014-10-22 07:30 -0400
        Re: (test) ? a:b Marko Rauhamaa <marko@pacujo.net> - 2014-10-22 14:41 +0300
        Re: (test) ? a:b Rustom Mody <rustompmody@gmail.com> - 2014-10-22 06:16 -0700
          Re: (test) ? a:b "BartC" <bc@freeuk.com> - 2014-10-22 19:08 +0100
            Re: (test) ? a:b Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-10-22 19:55 -0400
              Re: (test) ? a:b "BartC" <bc@freeuk.com> - 2014-10-23 11:50 +0100
                Re: (test) ? a:b Marko Rauhamaa <marko@pacujo.net> - 2014-10-23 16:44 +0300
                  Re: (test) ? a:b Ian Kelly <ian.g.kelly@gmail.com> - 2014-10-23 08:24 -0600
                  Re: (test) ? a:b Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-10-23 16:41 +0200
                    Re: (test) ? a:b Marko Rauhamaa <marko@pacujo.net> - 2014-10-23 19:20 +0300
                  Re: (test) ? a:b Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-24 19:38 +1100
                    Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-24 19:45 +1100
                    Re: (test) ? a:b Marko Rauhamaa <marko@pacujo.net> - 2014-10-24 12:37 +0300
                      Re: (test) ? a:b Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-25 00:07 +1100
                        Re: (test) ? a:b Ian Kelly <ian.g.kelly@gmail.com> - 2014-10-24 12:22 -0600
                          Re: (test) ? a:b Marko Rauhamaa <marko@pacujo.net> - 2014-10-24 21:46 +0300
                    Re: (test) ? a:b Dan Stromberg <drsalists@gmail.com> - 2014-10-24 10:20 -0700
                      Re: (test) ? a:b alister <alister.nospam.ware@ntlworld.com> - 2014-10-24 20:58 +0000
                        Re: (test) ? a:b Marko Rauhamaa <marko@pacujo.net> - 2014-10-25 00:02 +0300
                        Re: (test) ? a:b Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-25 16:03 +1100
                          Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-25 16:25 +1100
                          Re: (test) ? a:b Ned Batchelder <ned@nedbatchelder.com> - 2014-10-25 07:58 -0400
                          Re: (test) ? a:b Ian Kelly <ian.g.kelly@gmail.com> - 2014-10-25 07:53 -0600
                          Re: (test) ? a:b Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-10-25 14:11 -0400
                          Re: (test) ? a:b alister <alister.nospam.ware@ntlworld.com> - 2014-10-25 19:49 +0000
                          Re: (test) ? a:b Ben Finney <ben+python@benfinney.id.au> - 2014-10-26 07:45 +1100
                            Re: (test) ? a:b Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-26 11:10 +1100
                              Re: (test) ? a:b Ben Finney <ben+python@benfinney.id.au> - 2014-10-26 12:03 +1100
                                Re: (test) ? a:b Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-26 15:15 +1100
                                  Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-26 15:34 +1100
                                  Re: (test) ? a:b Terry Reedy <tjreedy@udel.edu> - 2014-10-26 17:12 -0400
                                  Re: (test) ? a:b Ben Finney <ben+python@benfinney.id.au> - 2014-10-27 11:38 +1100
                                  Re: (test) ? a:b MRAB <python@mrabarnett.plus.com> - 2014-10-27 01:40 +0000
                                  Re: (test) ? a:b Rustom Mody <rustompmody@gmail.com> - 2014-10-26 19:19 -0700
                              Re: (test) ? a:b Ben Finney <ben+python@benfinney.id.au> - 2014-10-26 12:10 +1100
                              Re: (test) ? a:b Joshua Landau <joshua@landau.ws> - 2014-10-27 01:55 +0000
                              Re: (test) ? a:b Ben Finney <ben+python@benfinney.id.au> - 2014-10-27 13:28 +1100
                                Re: (test) ? a:b Rustom Mody <rustompmody@gmail.com> - 2014-10-26 19:38 -0700
                              Re: (test) ? a:b Joshua Landau <joshua@landau.ws> - 2014-10-27 02:43 +0000
                              Re: (test) ? a:b Ben Finney <ben+python@benfinney.id.au> - 2014-10-27 13:56 +1100
                          Re: (test) ? a:b Dan Stromberg <drsalists@gmail.com> - 2014-10-25 15:34 -0700
                          Re: (test) ? a:b Ben Finney <ben+python@benfinney.id.au> - 2014-10-26 10:53 +1100
                          Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-26 11:01 +1100
                          Re: (test) ? a:b Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-26 01:09 +0100
                          Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-26 11:13 +1100
            Re: (test) ? a:b Vito De Tullio <vito.detullio@gmail.com> - 2014-10-23 06:55 +0200
        Re: (test) ? a:b Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-23 03:28 +1100
          Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-23 03:40 +1100
          Re: (test) ? a:b alister <alister.nospam.ware@ntlworld.com> - 2014-10-22 18:03 +0000
          Re: (test) ? a:b Matthew Ruffalo <mmr15@case.edu> - 2014-10-22 14:27 -0400
          Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-23 05:30 +1100
          Re: (test) ? a:b Ned Batchelder <ned@nedbatchelder.com> - 2014-10-22 16:11 -0400
      Re: (test) ? a:b Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-22 12:41 +0100
        Re: (test) ? a:b alister <alister.nospam.ware@ntlworld.com> - 2014-10-22 15:12 +0000
          Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-23 02:18 +1100
            Re: (test) ? a:b alister <alister.nospam.ware@ntlworld.com> - 2014-10-22 15:24 +0000
      Re: (test) ? a:b Dan Stromberg <drsalists@gmail.com> - 2014-10-22 09:09 -0700
    Re: (test) ? a:b Tobiah <toby@tobiah.org> - 2014-10-24 10:23 -0700
      Re: (test) ? a:b Chris Angelico <rosuav@gmail.com> - 2014-10-25 04:27 +1100
        Re: (test) ? a:b Tobiah <toby@tobiah.org> - 2014-10-24 11:31 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#79676

On Sat, 25 Oct 2014 07:58:14 -0400, Ned Batchelder <ned@nedbatchelder.com>
declaimed the following:


>
>You mention "standard Python idioms."  I think this style of 
>conditional-via-indexing is becoming quite uncommon, and is no longer 
>one of the standard Python idioms.  This is now in the category of 
>"outdated hack."
>
	That may be true for the case where the index is based upon a Boolean
expression...

	But the general form is still viable for either numeric indices (table
of functions) and switch/case style operations (replace the list with a
dictionary).

	The Boolean application is merely a specialization of a more general
idiom.


	The "true if cond else false" just doesn't fit my mind.

	Even HP RPL (where one might expect strangeness) uses

		if cond then true else false end

though being reverse polish overall, one could write

		cond if then true else false end

as "if" merely starts the block, and it is the "then" which evaluates the
condition, whose value is still the top of stack at that point. I'm too
lazy to see if one could do

		false true cond if then else end

which does have the problem of evaluating both false and true paths -- but
if no side-effects, might work: the "then" pulls the "cond", if true the
"else" takes the "true" and the "end" drops the "false" (and if "false" the
"else" drops the "true" and the "end" takes the "false")...


	The more in-line form, usable outside of RPL appears as a function

		ifte(cond, true, false)

which wasn't wanted for Python as it would evaluate both true and false (no
lazy evaluation; one would need to make a lambda for them)


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#79682

On Sat, 25 Oct 2014 16:03:16 +1100, Steven D'Aprano wrote:

> [Alister]
>> I had to mentally step through this before it became apparent what it
>> was doing,  can see places where it could be usefull (a switch
>> replacement) but it is not instantly obvious
> 
> Very little code is instantly obvious. Even when you know what the
> syntax means, you still have to understand the semantics, and sometimes
> that's far from obvious.
> 
> 
>> a = <value> if <condition> else <another Value>
>> 
>> is instantly obvious (at least to a native English speaker anyway)
> 
> Ha! And yet people have, and continue to, complain *bitterly* about the
> non-standard ordering of Python's ternary if, compared to C, standard
> if...else syntax, and English.

Not Me, I don't program i C & I don't want to it is too low level fro my 
liking (& I used to program in assembler for a living)


-- 
"You need tender loving care once a week - so that I can slap you into 
shape."
- Ellyn Mustard

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

#79683

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> Of course it won't be clear to *everyone* but it should be clear
> enough to people who are familiar with standard Python idioms. A
> concrete example should be more obvious than the fake example:
>
> title = ('Mr', 'Ms')[person.sex == 'F']
>
> which should be clear to anyone who understands indexing in Python and
> that True == 1 and False == 0.

I consider it an accident of history, and one which should not be
necessary to understand Python code.

In other words, I consider code which exploits the equality of True with
1, or False with 0, is code with a leaky abstraction and should be
fixed.

> Although that's probably better written as a dict lookup:
>
> title = {'M': 'Mr', 'F': 'Ms'}[person.sex]
>
> which is then more easily extended to support intersex and
> non-traditional[1] gender identities.

It's true that gender is not a binary, but even if it were, this would
be a bad idea.

A schema which blurs the distinction between boolean versus integer is a
code smell: it speaks to the high likelihood that the “flag” really
represents an entity which will soon have more than two states, and
should never have been represented as a boolean.

-- 
 \     “As scarce as truth is, the supply has always been in excess of |
  `\                                       the demand.” —Josh Billings |
_o__)                                                                  |
Ben Finney

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

#79694

Ben Finney wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
> 
>> Of course it won't be clear to *everyone* but it should be clear
>> enough to people who are familiar with standard Python idioms. A
>> concrete example should be more obvious than the fake example:
>>
>> title = ('Mr', 'Ms')[person.sex == 'F']
>>
>> which should be clear to anyone who understands indexing in Python and
>> that True == 1 and False == 0.
> 
> I consider it an accident of history, and one which should not be
> necessary to understand Python code.
> 
> In other words, I consider code which exploits the equality of True with
> 1, or False with 0, is code with a leaky abstraction and should be
> fixed.

I suspect that Guido and the core developers disagree with you, since they
had the opportunity to fix that in Python 3 and didn't.

Equating True with 1 and False with 0 is fundamental to many programming
languages, but more importantly Boolean Algebra itself normally identifies
True with 1 and False with 0. 

https://en.wikipedia.org/wiki/Boolean_algebra
http://mathworld.wolfram.com/BooleanAlgebra.html

Admittedly this is only a convention, and you're welcome to invent your own
convention, but when doing so you should be aware that Python's convention
is mathematically sound and, well, conventional.

One example of where treating True and False as 1 and 0 is useful is that it
makes counting operations very simple, e.g. counting the number of blank
lines:

sum(not line.strip() for line in lines)

If you reject implicit or explicit bool-to-int conversions:

sum(1 if not line.strip() else 0 for line in lines)

or for compatibility with Python 2.4:

sum({'': 0}.get(line.strip(), 1) for line in lines)

which I consider far less obvious than the straightforward summation of True
values. Sometimes making things *too* abstract is worse than allowing an
abstraction to leak.


-- 
Steven

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

#79697

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> I suspect that Guido and the core developers disagree with you, since
> they had the opportunity to fix that in Python 3 and didn't.

That doesn't follow; there are numerous warts in Python 2 that were not
fixed in Python 3. As I understand it, the preservation of bool–int
equality has more to do with preserving backward compatibility.

I agree with the decision, because this isn't an issue which often leads
to *incorrect* code. But I maintain that it's an unfortunate and
needlessly confusing wart of the language.

> One example of where treating True and False as 1 and 0 is useful is
> that it makes counting operations very simple, e.g. counting the
> number of blank lines:
>
> sum(not line.strip() for line in lines)
> sum(1 if not line.strip() else 0 for line in lines)
> sum({'': 0}.get(line.strip(), 1) for line in lines)

These all look ludicrous and explain nothing about intent, to my
reading. The ‘bool’ type exists precisely because there is a concept to
be represented which is distinct from integers.

Using a sum on non-numeric values just cracks the abstraction open
needlessly. Once I figure out what is going on, I'm left wondering why
the coder chose something so obfuscatory to their intent.

This is short and clear and needs no leaking of the underlying bool
implementation::

    len(True for line in lines if line.strip())

> which I consider far less obvious than the straightforward summation
> of True values.

Why sum them at all? You aren't interested in them as numbers, you're
just asking how many objects meet a criterion. That calls not for ‘sum’,
but ‘len’. There's no need to rely on an underlying ‘int’ operation just
to count objects.

The fact that summing them gives the same answer as simply asking how
many there are, demonstrates that nothing is gained by peeking into the
implementation. The example I give above works exactly as well with no
‘int’ underlying the ‘bool’ type at all.

-- 
 \      “The way to build large Python applications is to componentize |
  `\             and loosely-couple the hell out of everything.” —Aahz |
_o__)                                                                  |
Ben Finney

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

#79702

Ben Finney wrote:

> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
> 
>> I suspect that Guido and the core developers disagree with you, since
>> they had the opportunity to fix that in Python 3 and didn't.
> 
> That doesn't follow; there are numerous warts in Python 2 that were not 
> fixed in Python 3. As I understand it, the preservation of bool–int
> equality has more to do with preserving backward compatibility.

On reviewing PEP 285, I think it is safe to say that Guido *explicitly*
wants bools to be ints, not just for backwards compatibility:

    4) Should we strive to eliminate non-Boolean operations on bools
       in the future, through suitable warnings, so that for example
       True+1 would eventually (in Python 3000) be illegal?

    => No.

       There's a small but vocal minority that would prefer to see
       "textbook" bools that don't support arithmetic operations at
       all, but most reviewers agree with me that bools should always
       allow arithmetic operations.

http://legacy.python.org/dev/peps/pep-0285/


> I agree with the decision, because this isn't an issue which often leads
> to *incorrect* code. But I maintain that it's an unfortunate and
> needlessly confusing wart of the language.

That puts you in the small but vocal minority :-)


>> One example of where treating True and False as 1 and 0 is useful is
>> that it makes counting operations very simple, e.g. counting the
>> number of blank lines:
>>
>> sum(not line.strip() for line in lines)
>> sum(1 if not line.strip() else 0 for line in lines)
>> sum({'': 0}.get(line.strip(), 1) for line in lines)
> 
> These all look ludicrous and explain nothing about intent, to my
> reading.
[...]
> I'm left wondering why
> the coder chose something so obfuscatory to their intent.

"Ludicrous" and "obfuscatory". They're awfully strong words.

Do you really not see the connection between counting and summing? If so,
that would put you in a truly small minority. The connection between adding
and counting has been known to Western mathematics since at least the
ancient Greeks, if not even earlier, and we teach it to school children. If
you have three apples, and I have two apples, then in total we have (count
the apples: one two three, four five) five apples. Pre-schoolers learn
this. I'm sure it's not too difficult for programmers.


> This is short and clear and needs no leaking of the underlying bool
> implementation::
> 
>     len(True for line in lines if line.strip())

I see that in a later email you discovered your unfortunate bug in this, and
corrected it to this:

    len([True for line in lines if line.strip()])

Alas, you missed the bigger bug: I'm counting *blank lines*, not non-blank
lines. You need a `not` in there.

You mentioned intent before. I wonder what your intention is, to needlessly
build a potentially gigantic list of identical values, only to then throw
the list away. Could be worse; you might have written

    [True for line in lines if not line.strip()].count(True)

Since the list items exist only to be counted, the actual item used makes no
difference. You could use any value at all, or even a different value each
time:

    len([random.random() for line in lines if not line.strip()])

What is your reason for the choice of True as the tally marker? It doesn't
clarify your intent, or make it more obvious that you're counting the
number of non-empty lines. If you wanted to suggest a tally:

    len(['/' for line in lines if not line.strip()])

at least looks like a tally: //// makes four. Using a bool doesn't make this
any clearer, and you don't even have the excuse that it's efficient,
because it isn't.

Let's get rid of the list comp and write a straightforward translation:

temp = []
for line in lines:
    if not line.strip():
        temp.append(True)
result = len(temp)
del temp


I don't consider that sensible code at all. Why waste time building the
temporary list when all we want is a counter?

result = 0
for line in lines:
    if not line.strip():
        result += 1


which can be simplified to:

result = 0
for line in lines:
    result += not line.strip()


I agree with you that this breaks the abstraction "bools are abstract
enumerations, not ints", but that abstraction is not part of Python. If I
objected to code like this:

    types = [int, str, list, dict]
    for t in types:
        do_something_with(t)

on the basis that we shouldn't treat types as values, because that breaks
the abstraction that "types are not values, they're a different kind of
thing known only to the compiler" (as in Java), I expect that you would
have no hesitation in telling me that my objection was invalid. Making
types be non-values may, or may not, be a reasonable programming model, but
it's not Python's programming model. In Python, types are themselves
objects and first-class values. Objecting to Python code because it
violates a norm from some other language is, frankly, silly.

The abstraction "bools are abstract enumerations different from ints" may be
a reasonable abstraction, but it's not part of Python's programming model

[...]
>> which I consider far less obvious than the straightforward summation
>> of True values.
> 
> Why sum them at all? You aren't interested in them as numbers, you're
> just asking how many objects meet a criterion. That calls not for ‘sum’,
> but ‘len’. There's no need to rely on an underlying ‘int’ operation just
> to count objects.

A length (in the sense of the discrete count of the number of items) is
fundamentally a sum of ones. That is what counting *is*.


> The fact that summing them gives the same answer as simply asking how
> many there are, demonstrates that nothing is gained by peeking into the
> implementation. The example I give above works exactly as well with no
> ‘int’ underlying the ‘bool’ type at all.

And if you were programming in a language where bools were not a sub-type of
int, perhaps your code might be preferred. But even then, why build an
unnecessarily large list, only to throw it away unused apart from counting
the items? You can just count the items as they appear. Even in some other
hypothetical language with abstract bools, say, Pascal, I'd write it as:

    sum(1 for line in lines if not line.strip())

rather than build a full list that I don't care about.


-- 
Steven

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

#79703

On Sun, Oct 26, 2014 at 3:15 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Since the list items exist only to be counted, the actual item used makes no
> difference. You could use any value at all, or even a different value each
> time:
>
>     len([random.random() for line in lines if not line.strip()])
>
> What is your reason for the choice of True as the tally marker? It doesn't
> clarify your intent, or make it more obvious that you're counting the
> number of non-empty lines.

Personally, I'd use the original value. When you're counting
something, it's common to count that thing, rather than some stand-in.

len([line for line in lines if not line.strip()])

But that's no better than anything else. The only significance is that
it feels more like counting a filtered portion of the list.

ChrisA

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

#79728

On 10/26/2014 12:15 AM, Steven D'Aprano wrote:
> Ben Finney wrote:
>
>> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>>
>>> I suspect that Guido and the core developers disagree with you, since
>>> they had the opportunity to fix that in Python 3 and didn't.
>>
>> That doesn't follow; there are numerous warts in Python 2 that were not
>> fixed in Python 3. As I understand it, the preservation of bool–int
>> equality has more to do with preserving backward compatibility.
>
> On reviewing PEP 285, I think it is safe to say that Guido *explicitly*
> wants bools to be ints, not just for backwards compatibility:
>
>      4) Should we strive to eliminate non-Boolean operations on bools
>         in the future, through suitable warnings, so that for example
>         True+1 would eventually (in Python 3000) be illegal?
>
>      => No.
>
>         There's a small but vocal minority that would prefer to see
>         "textbook" bools that don't support arithmetic operations at
>         all, but most reviewers agree with me that bools should always
>         allow arithmetic operations.
>
> http://legacy.python.org/dev/peps/pep-0285/

Thank you for digging this up.  I was one of the 'most reviewers'.

Even though filter now returns an iterator, so that one can write

sum(1 for _ in filter(None, iterable_of_bools))

without creating an unneeded itermediate list, I still prefer

sum(iterable_of_bools)

for efficiency not only for the machine but also for me writing and reading.

[snip of fine disquisition on the subject to which I have nothing to add]

-- 
Terry Jan Reedy

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

#79738

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> Do you really not see the connection between counting and summing?

Connection? Of course. But I also see a huge distinction. I'm surprised
you could misunderstand my position to the extent you think such a
question needs to be asked.

The difference between “sum these values” versus “count these values” is
important. That's at the root of why I find it confusingly wrong to sum
True or False values.

Do you really not see the distinction between counting and summing?

The question is just as silly that way.

> If you have three apples, and I have two apples, then in total we have
> (count the apples: one two three, four five) five apples.

If you have three apples in one basket, and I have two apples in one
basket, “sum the baskets” is quite a different operation from “count the
baskets”.

    [3, 2]

What is the sum of those values?

How many values are there?

The distinction between those is why I find it unhelpful to express “how
many values?” with “sum them”.

> Alas, you missed the bigger bug: I'm counting *blank lines*, not
> non-blank lines. You need a `not` in there.

Which is, shall we say, not incompatible with the position that the
“count the matches by summing bools” method is an unclear expression of
intent :-)

-- 
 \     “Sittin' on the fence, that's a dangerous course / You can even |
  `\       catch a bullet from the peace-keeping force” —Dire Straits, |
_o__)                                   _Once Upon A Time In The West_ |
Ben Finney

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

#79742

On 2014-10-27 00:38, Ben Finney wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>
>> Do you really not see the connection between counting and summing?
>
> Connection? Of course. But I also see a huge distinction. I'm surprised
> you could misunderstand my position to the extent you think such a
> question needs to be asked.
>
> The difference between “sum these values” versus “count these values” is
> important. That's at the root of why I find it confusingly wrong to sum
> True or False values.
>
> Do you really not see the distinction between counting and summing?
>
> The question is just as silly that way.
>
>> If you have three apples, and I have two apples, then in total we have
>> (count the apples: one two three, four five) five apples.
>
> If you have three apples in one basket, and I have two apples in one
> basket, “sum the baskets” is quite a different operation from “count the
> baskets”.
>
>      [3, 2]
>
> What is the sum of those values?
>
> How many values are there?
>
Those are ints. The question is whether you can sum bools.

Python's way is to say that it's counting how many True there are.

Sometimes it's useful; pragmatism beats purity, and all that.

> The distinction between those is why I find it unhelpful to express “how
> many values?” with “sum them”.
>
>> Alas, you missed the bigger bug: I'm counting *blank lines*, not
>> non-blank lines. You need a `not` in there.
>
> Which is, shall we say, not incompatible with the position that the
> “count the matches by summing bools” method is an unclear expression of
> intent :-)
>

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

#79745

On Sunday, October 26, 2014 9:45:22 AM UTC+5:30, Steven D'Aprano wrote:
> http://legacy.python.org/dev/peps/pep-0285/
<snipped>
> Ben Finney wrote:
> 
> 
> > I agree with the decision, because this isn't an issue which often leads
> > to *incorrect* code. But I maintain that it's an unfortunate and
> > needlessly confusing wart of the language.
> 
> That puts you in the small but vocal minority :-)

I'm sure that as the author of stats module you know of 'sampling error'!

Hint: There are two rather different populations to consider here for drawing the sample

- pythonistas
- textbook-istas

Analogous to another oft-seen argument -- variables.

A python variable is time-varying (like most programming languages)
A python variable is not a mathematical variable.

Historically: 1st HLL was FORTRAN which first introduced variables
in trying to come closer to math (note the name FORmula TRANslator)

Fortran's approximation was quite a good attempt for 1957.
Less and less so as people understood the consequences.
Until 1978 its creator was awarded for his creation and in his
acceptance apologized for his mistakes
-- Section 4 http://web.stanford.edu/class/cs242/readings/backus.pdf

tl;dr People make mistakes. Mistakes can be corrected


==================
Of course
1. There are the logical operators and, xor
2. Put them into a certain config -- half-adder 
   https://en.wikipedia.org/wiki/Adder_%28electronics%29#Half_adder
3. [Keep reading down]. ..
   full-adder
4. Ripple-carry adder
   :
   :
5. ALU ie Arithmetic Logic Unit

IOW arithmetic/logic distinctions are fuzzy.

"Distinctions are fuzzy" ≠ "Should not be made" [In my book!]

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

#79699

Ben Finney <ben+python@benfinney.id.au> writes:

> This is short and clear and needs no leaking of the underlying bool
> implementation::
>
>     len(True for line in lines if line.strip())

Correction::

    len([True for line in lines if line.strip()])

-- 
 \     “Our task must be to free ourselves from our prison by widening |
  `\    our circle of compassion to embrace all humanity and the whole |
_o__)                       of nature in its beauty.” —Albert Einstein |
Ben Finney

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

#79744

On 26 October 2014 01:03, Ben Finney <ben+python@benfinney.id.au> wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>
>> I suspect that Guido and the core developers disagree with you, since
>> they had the opportunity to fix that in Python 3 and didn't.
>
> That doesn't follow; there are numerous warts in Python 2 that were not
> fixed in Python 3. As I understand it, the preservation of bool–int
> equality has more to do with preserving backward compatibility.

Guido van Rossum answered Jul 28 '11 at 21:20,
http://stackoverflow.com/questions/3174392/is-it-pythonic-to-use-bools-as-ints
> False==0 and True==1, and there's nothing wrong with that.

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

#79746

Joshua Landau <joshua@landau.ws> writes:

> Guido van Rossum answered Jul 28 '11 at 21:20,
> http://stackoverflow.com/questions/3174392/is-it-pythonic-to-use-bools-as-ints
> > False==0 and True==1, and there's nothing wrong with that.

Guido is incorrect. I've already stated what's wrong.

That's different from saying I want to change how Python behaves *now*,
of course. But to say “there's nothing wrong with that” dismisses the
problems without addressing them. Guido isn't perfect, so that's okay.

-- 
 \        “Telling pious lies to trusting children is a form of abuse, |
  `\                    plain and simple.” —Daniel Dennett, 2010-01-12 |
_o__)                                                                  |
Ben Finney

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

#79748

On Monday, October 27, 2014 7:59:04 AM UTC+5:30, Ben Finney wrote:
> Joshua Landau writes:
> 
> > Guido van Rossum answered Jul 28 '11 at 21:20,
> > http://stackoverflow.com/questions/3174392/is-it-pythonic-to-use-bools-as-ints
> > > False==0 and True==1, and there's nothing wrong with that.
> 
> Guido is incorrect. I've already stated what's wrong.
> 
> That's different from saying I want to change how Python behaves *now*,
> of course. But to say "there's nothing wrong with that" dismisses the
> problems without addressing them. Guido isn't perfect, so that's okay.

Yes; thats my position also (here and in general).

Language changes can be (hugely) disruptive.
The cost/benefit of disruption/improvement is always to be considered

Does not mean the choices are perfect.

In particular, when introducing a beginner, its best if teachers are upfront 
about goofups. It helps everyone. Helps...

- the noob who is saved from self-flagellating "Am I a fool?"
- helps the python ecosystem: "These guys are straightforward; dont cover
up their mistakes"
- etc -- eg noob's future employer

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

#79749

On 27 October 2014 02:28, Ben Finney <ben+python@benfinney.id.au> wrote:
> Joshua Landau <joshua@landau.ws> writes:
>
>> Guido van Rossum answered Jul 28 '11 at 21:20,
>> http://stackoverflow.com/questions/3174392/is-it-pythonic-to-use-bools-as-ints
>> > False==0 and True==1, and there's nothing wrong with that.
>
> Guido is incorrect. I've already stated what's wrong.

You were arguing about what Guido thinks. I'm pretty sure Guido gets
first say in that, regardless of whether anyone agrees with him.

Regardless, I feel you're making this out as a black and white issue.
Guido isn't incorrect, he just has a different opinion. Designing a
language and calling things "wrong" or "right" gets you Haskell. You
can discuss the advantages of each approach without drawing lines in
the sand. Although if you do want a language like Haskell, there are a
few great choices to chose from.

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

#79750

Joshua Landau <joshua@landau.ws> writes:

> On 27 October 2014 02:28, Ben Finney <ben+python@benfinney.id.au> wrote:
> > Guido is incorrect. I've already stated what's wrong.
>
> You were arguing about what Guido thinks.

I don't know where I did that; to my knowledge, this is the first time
I've mentioned Guido, and it's in rebuttal to his authority on the issue
of whether “there's nothing wrong with” bool-as-a-special-int.

(On the separate issue of whether Guido is an authority on how Python
will behave, I haven't even commented. To be clear: yes, he is the BDFL
and therefore is authoritative on that issue.)

> Regardless, I feel you're making this out as a black and white issue.

There either is something problematic with a behaviour, or there isn't.

The *degree* of wrongness can vary. I'm merely pointing out that, in
this case, it's non-zero.

-- 
 \     “I must say that I find television very educational. The minute |
  `\       somebody turns it on, I go to the library and read a book.” |
_o__)                                                    —Groucho Marx |
Ben Finney

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

#79688

On Sat, Oct 25, 2014 at 1:45 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>> title = ('Mr', 'Ms')[person.sex == 'F']
>>
>> which should be clear to anyone who understands indexing in Python and
>> that True == 1 and False == 0.
>
> I consider it an accident of history, and one which should not be
> necessary to understand Python code.
>
> In other words, I consider code which exploits the equality of True with
> 1, or False with 0, is code with a leaky abstraction and should be
> fixed.

I don't like the (a, b)[True] thing, but I use the fact that True is 1
and False is 0 sometimes.

EG, if I have 3 mutually exclusive command line options, I'll do something like:

if option_a + option_b + option_c != 1:
   sys.stderr.write('{}: -a, -b and -c are mutually
exclusive\n'.format(sys.argv[0]))

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

#79692

Dan Stromberg <drsalists@gmail.com> writes:

> EG, if I have 3 mutually exclusive command line options, I'll do
> something like:
>
> if option_a + option_b + option_c != 1:
>    sys.stderr.write('{}: -a, -b and -c are mutually exclusive\n'.format(sys.argv[0]))

That is an excellent illustration of why exploiting this accidental
property of True and False leads to obfuscated code. The above test
gives me no clue that we're operating on boolean values, nor that we're
testing for exclusive options.

The error message bears no obvious relation to the test, and if I was
tracking down that error message I'd have no hint from the code why the
test is written that way. An explanatory comment would be needed, but
that's a strong sign IMO that instead the test should be re-written to
be much more obvious.

-- 
 \           “Never express yourself more clearly than you are able to |
  `\                                               think.” —Niels Bohr |
_o__)                                                                  |
Ben Finney

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

#79693

On Sun, Oct 26, 2014 at 10:53 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Dan Stromberg <drsalists@gmail.com> writes:
>
>> EG, if I have 3 mutually exclusive command line options, I'll do
>> something like:
>>
>> if option_a + option_b + option_c != 1:
>>    sys.stderr.write('{}: -a, -b and -c are mutually exclusive\n'.format(sys.argv[0]))
>
> That is an excellent illustration of why exploiting this accidental
> property of True and False leads to obfuscated code. The above test
> gives me no clue that we're operating on boolean values, nor that we're
> testing for exclusive options.

Would it be more readable thus?

if len([opt for opt in (option_a, option_b, option_c) if opt]) != 1:

Because that's what it's doing. I think treating bools as numbers is
fine. Matter of opinion I guess.

ChrisA

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web