Steve R. Hastings [EMAIL PROTECTED] (SRH) wrote:
[snip]
SRH vowels = frozenset(aeiouAEIOU)
SRH f = open(a_file.txt) # note that f is an iterator
SRH counts = tally(line[0] in vowels for line in f)
tally([line[0] in vowels for line in f])
SRH # counts is a dict; counts.keys() == [False, True]
Steve R. Hastings wrote:
On Fri, 31 Mar 2006 16:29:00 -0800, Paul Rubin wrote:
I think S and all(S) is the right way to express that, if that's
what's intended.
I still would like a standard function, because S and all(S) does not
work with iterators. I proposed one possible function,
Ron Adam [EMAIL PROTECTED] writes:
true_count, count = countall(S), len(S)
In general it's preferable to not rely on len being available, since
these are arbitrary iterators.
--
http://mail.python.org/mailman/listinfo/python-list
On Sat, 01 Apr 2006 02:06:29 -0600, Ron Adam wrote:
true_count, count = countall(S), len(S)
Unfortunately, this does not solve the problem.
An iterator yields its values only once. If you have an iterator itr,
you cannot do all(itr) and then do len(itr). Whichever one you do first
will
On Sat, 01 Apr 2006 00:38:08 -0800, Steve R. Hastings wrote:
my proposed truecount() returns a tuple, with the length and
the count of true values.
I never liked the name truecount(), and the more I think about it, the
less I like the function. It should either solve a very important need,
or
Em Sáb, 2006-04-01 às 08:35 -0800, Steve R. Hastings escreveu:
def tally(seq, d=None):
if d == None:
d = {}
for x in seq:
if x in d:
d[x] += 1
else:
d[x] = 1
return d
Two changes:
- Use is None.
- Use try ... except instead
On Sat, 01 Apr 2006 14:35:58 -0300, Felipe Almeida Lessa wrote:
Two changes:
- Use is None.
- Use try ... except instead of in
Yes.
Maybe you don't like my version, and the gains aren't that much, but
please use is None instead of == None.
Actually, I do like your version. And I try to
Steve R. Hastings wrote:
Here is a function called tally(). It reduces a list to a dictionary
of counts, with one key for each value from the list. The value for
each key is the count of how many times it appeared in the list.
def tally(seq, d=None):
if d == None:
d = {}
Steve R. Hastings wrote:
On Sat, 01 Apr 2006 14:35:58 -0300, Felipe Almeida Lessa wrote:
Two changes:
- Use is None.
- Use try ... except instead of in
Yes.
Maybe you don't like my version, and the gains aren't that much, but
please use is None instead of == None.
Actually, I do
Ron Adam wrote:
Steve R. Hastings wrote:
This neatly replaces truecount(), and you can use it for other things as
well.
if True in talley(S): do_somthing()
Works for me... ;-)
Cheers,
Ron
Actulley talley isn't needed for this...
if True in S: do_domething()
That's
Op 2006-03-30, Paul McGuire schreef [EMAIL PROTECTED]:
Antoon Pardon [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Op 2006-03-30, Steven D'Aprano schreef [EMAIL PROTECTED]:
So, these flying elephants -- are they pink or not?
They are both.
That would make them Schrödinger
I don't think that there will be any valid examples.
all(list) simply means every element of the list evaluates to True.
This is trivially true in the case of the empty list. This is logically
equivalent to There are no elements in the list which evaluate to
False.
any(list) simply means at
Steve R. Hastings wrote:
Therefore, I propose that all() should work as if it were written this way:
def all(S):
ret_val = False
for x in S:
ret_val = True
if not x:
return False
return ret_val
Comments?
Ant wrote:
all(list) simply means
Ron Adam wrote:
Carl Banks wrote:
In Python, yes and no are the only possible answers. Probably the only
analogous thing you could do in Python would be for all() to raise
ValueError when passed an empty sequence.
There is also 'None' which serves a similar purpose of indicating an
Carl Banks wrote:
Ron Adam wrote:
Carl Banks wrote:
In Python, yes and no are the only possible answers. Probably the only
analogous thing you could do in Python would be for all() to raise
ValueError when passed an empty sequence.
There is also 'None' which serves a similar purpose of
lol!
--
http://mail.python.org/mailman/listinfo/python-list
Ron Adam [EMAIL PROTECTED] writes:
The 'not not S' is just a conversion to bool. Is the following less
contorted to you?
bool([])
False
Oh ok. Yes, bool(S) is much less contorted than not not S.
'Is all True' isn't the same as 'Has all True'. As I said, I'm not
questioning the
On Fri, 31 Mar 2006 16:29:00 -0800, Paul Rubin wrote:
I think S and all(S) is the right way to express that, if that's
what's intended.
I still would like a standard function, because S and all(S) does not
work with iterators. I proposed one possible function, truecount(S), that
returns a
Steven D'Aprano [EMAIL PROTECTED] writes:
Think of it this way: if all(seq) is true, shouldn't it be the case
that you can point to a specific element in seq that is true?
No, all(seq) is true if you can't point to a specific element in seq
that's false.
--
Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
Think of it this way: if all(seq) is true, shouldn't it be the case
that you can point to a specific element in seq that is true?
No, all(seq) is true if you can't point to a specific element in seq
that's false.
No, all(seq)
Duncan Booth wrote:
Ron Adam wrote:
Where we are assembling widgets in a manufacturing plant. Where we don't
want to go to the next step until *all* the sub parts are present.
if all(part.status == 'present' for part in unit):
do_release()
Oops! Some empty bins showed up at the next
Steven D'Aprano wrote:
Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
Think of it this way: if all(seq) is true, shouldn't it be the case
that you can point to a specific element in seq that is true?
No, all(seq) is true if you can't point to a specific element in seq
Steven D'Aprano wrote:
Okay, Ron's example wasn't the best. How about this
one, from chess:
The intention is to play cautiously if all threatened
pieces are valuable, and daringly otherwise.
Isn't that example even worse? Compare:
- You have one of your valuable pieces threatened. You
Steven D'Aprano wrote:
Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
Think of it this way: if all(seq) is true, shouldn't it be the case
that you can point to a specific element in seq that is true?
No, all(seq) is true if you can't point to a specific element in seq
Duncan Booth wrote:
Ron Adam wrote:
Where we are assembling widgets in a manufacturing plant. Where we don't
want to go to the next step until *all* the sub parts are present.
if all(part.status == 'present' for part in unit):
do_release()
Oops! Some empty bins showed up at the
Steven D'Aprano wrote:
Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
Think of it this way: if all(seq) is true, shouldn't it be the case
that you can point to a specific element in seq that is true?
No, all(seq) is true if you can't point to a specific element in seq
Ron Adam wrote:
hasall(S, True, lambda n: n=42)
That was suppose to be:
hasall(S, True, lambda n: n==42)
--
http://mail.python.org/mailman/listinfo/python-list
Georg Brandl wrote:
Steven D'Aprano wrote:
all(flying elephants which are pink) = true
all(flying elephants which are not pink) = true
So, these flying elephants -- are they pink or not?
No, you ask two different sets whether they are true.
No, there is only one empty set.
Relevant to this
Marcin Ciura wrote:
all(flying elephants which are not pink) = true
So, these flying elephants -- are they pink or not?
No, you ask two different sets whether they are true.
No, there is only one empty set.
who said anything about empty sets ?
/F
--
Op 2006-03-30, Steven D'Aprano schreef [EMAIL PROTECTED]:
Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
Think of it this way: if all(seq) is true, shouldn't it be the case
that you can point to a specific element in seq that is true?
No, all(seq) is true if you can't point
Antoon Pardon [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Op 2006-03-30, Steven D'Aprano schreef [EMAIL PROTECTED]:
So, these flying elephants -- are they pink or not?
They are both.
That would make them Schrödinger elephants!
-- Paul
--
Steven D'Aprano [EMAIL PROTECTED] writes:
No, all(seq) is true if you can't point to a specific element in seq
that's false.
No, all(seq) is true if every element in seq is true. Surely that's a
more intuitive definition than your definition by what you can't do.
They are different? I'd
On Thu, 30 Mar 2006 11:28:54 -0800, Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
No, all(seq) is true if you can't point to a specific element in seq
that's false.
No, all(seq) is true if every element in seq is true. Surely that's a
more intuitive definition than your
Steven D'Aprano [EMAIL PROTECTED] writes:
No, all(seq) is true if every element in seq is true. Surely that's a
more intuitive definition than your definition by what you can't do.
They are different?
Of course they are different -- they differ in the case of an empty
sequence.
I don't
Steven D'Aprano wrote:
On Thu, 30 Mar 2006 11:28:54 -0800, Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
No, all(seq) is true if you can't point to a specific element in seq
that's false.
No, all(seq) is true if every element in seq is true. Surely that's a
more
Carl Banks wrote:
In Python, yes and no are the only possible answers. Probably the only
analogous thing you could do in Python would be for all() to raise
ValueError when passed an empty sequence.
There is also 'None' which serves a similar purpose of indicating an
invalid value when
Alex Martelli wrote:
all(flying elephants which are not pink) = true
So, these flying elephants -- are they pink or not?
No, you ask two different sets whether they are true.
No, there is only one empty set.
who said anything about empty sets ?
Universally-false predicate
Ron Adam [EMAIL PROTECTED] writes:
In this view and empty set can be True for all(). Is it posible
'all([])' is undefined? Here, none() and all() return contradicting
values. So maybe the correct version may be...
I don't see any contradiction. all([]) and none([]) are both true.
Anyway,
I'm completely on board with the semantics for any(). But all() bothers
me. If all() receives an empty list, it will return True, and I don't
like that. To me, all() should be a more restrictive function than any(),
and it bothers me to see a case where any() returns False but all()
Paul Rubin wrote:
Ron Adam [EMAIL PROTECTED] writes:
In this view and empty set can be True for all(). Is it posible
'all([])' is undefined? Here, none() and all() return contradicting
values. So maybe the correct version may be...
I don't see any contradiction. all([]) and none([])
Ron Adam [EMAIL PROTECTED] writes:
Just thinking about things. I really just want what is best for
Python in the long term and am not trying to be difficult.
I'm sorry, maybe it's the math geek in me, but I just see all those
suggestions about not not S as being contorted. It's obvious to me
Steve R. Hastings wrote:
I'm completely on board with the semantics for any(). But all() bothers
me. If all() receives an empty list, it will return True, and I don't
like that. To me, all() should be a more restrictive function than any(),
and it bothers me to see a case where any()
At risk of flogging a dead horse...
On Wed, 29 Mar 2006 01:01:00 -0800, vdrab wrote:
I'm completely on board with the semantics for any(). But all() bothers
me. If all() receives an empty list, it will return True, and I don't
like that. To me, all() should be a more restrictive function
Steven D'Aprano [EMAIL PROTECTED] writes:
While the implemented behaviour might be more practical than the
alternatives, it is still worrying paradoxical. If All sheep are woolly,
then obviously it must also be true that Any sheep is woolly. More
formally, if all(X), then any(X) -- except for
[Steven D'Aprano]
...
While the implemented behaviour might be more practical than the
alternatives, it is still worrying paradoxical. If All sheep are woolly,
then obviously it must also be true that Any sheep is woolly. More
formally, if all(X), then any(X) -- except for the case of empty
On Wed, 29 Mar 2006 21:34:08 +1000, Steven D'Aprano wrote:
While the implemented behaviour might be more practical than the
alternatives, it is still worrying paradoxical. If All sheep are woolly,
then obviously it must also be true that Any sheep is woolly. More
formally, if all(X), then
Paul Rubin wrote:
Ron Adam [EMAIL PROTECTED] writes:
Just thinking about things. I really just want what is best for
Python in the long term and am not trying to be difficult.
I'm sorry, maybe it's the math geek in me, but I just see all those
suggestions about not not S as being
Carl Banks wrote:
Steve R. Hastings wrote:
I'm completely on board with the semantics for any(). But all() bothers
me. If all() receives an empty list, it will return True, and I don't
like that. To me, all() should be a more restrictive function than any(),
and it bothers me to see a case
Ron Adam wrote:
Where we are assembling widgets in a manufacturing plant. Where we don't
want to go to the next step until *all* the sub parts are present.
if all(part.status == 'present' for part in unit):
do_release()
Oops! Some empty bins showed up at the next assembly station.
Tim Peters wrote:
In the all() example, if there *are* no values in S, then none of the
values can be != 0, and IMHO all() should return False.
That would break everything mentioned above. Think of it another way:
if all(seq) is false, shouldn't it be the case that you can point to
a
So, Python 2.5 will have new any() and all() functions.
http://www.python.org/dev/peps/pep-0356/
any(seq) returns True if any value in seq evaluates true, False otherwise.
all(seq) returns True if all values in seq evaluate true, False otherwise.
I have a question: what should these functions
Steve R. Hastings [EMAIL PROTECTED] writes:
In the all() example, if there *are* no values in S, then none of the
values can be != 0, and IMHO all() should return False.
That goes against the usual meaning of all in, say, mathematical logic.
Usually, for all X in S, PRED(x) is true means:
[Steve R. Hastings]
So, Python 2.5 will have new any() and all() functions.
http://www.python.org/dev/peps/pep-0356/
any(seq) returns True if any value in seq evaluates true, False otherwise.
all(seq) returns True if all values in seq evaluate true, False otherwise.
I have a question:
Paul Rubin http://[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Steve R. Hastings [EMAIL PROTECTED] writes:
In the all() example, if there *are* no values in S, then none of the
values can be != 0, and IMHO all() should return False.
That goes against the usual meaning of all
Steve R. Hastings [EMAIL PROTECTED] writes:
So, Python 2.5 will have new any() and all() functions.
http://www.python.org/dev/peps/pep-0356/
And there was much rejoicing.
any(seq) returns True if any value in seq evaluates true, False otherwise.
Yep.
all(seq) returns True if all values in
Steve R. Hastings [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
So, Python 2.5 will have new any() and all() functions.
http://www.python.org/dev/peps/pep-0356/
any(seq) returns True if any value in seq evaluates true, False otherwise.
all(seq) returns True if all values in seq
Thank you very much for explaining this. And so thoroughly!
Of course I withdraw all objections. :-)
--
Steve R. HastingsVita est
[EMAIL PROTECTED]http://www.blarg.net/~steveha
--
http://mail.python.org/mailman/listinfo/python-list
Paul McGuire [EMAIL PROTECTED] writes:
Usually, for all X in S, PRED(x) is true means:
there does not exist X in S so that PRED(x) is false.
How do you get this usually stuff? I would agree that this is usually
implemented as a short-circuited loop through the list, that breaks out at
Paul McGuire enlightened us with:
That goes against the usual meaning of all in, say, mathematical
logic.
Usually, for all X in S, PRED(x) is true means: there does not
exist X in S so that PRED(x) is false.
How do you get this usually stuff?
From its mathematical definition.
I would
Paul McGuire wrote:
Paul Rubin http://[EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
To my mind, the *meaning* of all() is that every element in the list asserts
True. But this is with an initial assumption that all() is False, unless I
test every value and find them to be True.
60 matches
Mail list logo
