I don't remember making such a mistake ever before, but it might have
happened. -= is a convenient operator so I've probably used it a lot.
Anyway, I found that flake8 flagged this as
E225 missing whitespace around operator
and it's the only linter of pylint, flake8 and pyflake that detects this
On 3/14/23 18:50, Rob Cliffe wrote:
On 14/03/2023 21:28, avi.e.gr...@gmail.com wrote:
Type hints are actually situationally quite useful (though yes, kind of
hard to understand when you first come across their use, largely because
of things like Union). And I wouldn't recommend their use i
On Tue, 14 Mar 2023 22:15:34 GMT, Gilmeh Serda wrote:
> On Mon, 13 Mar 2023 22:26:20 +0100, Morten W. Petersen wrote:
>
>> numbers for calculations didn't add up. It went into negative numbers,
>> when that shouldn't have been possible.
>
> We have all written code that makes us wonder why the
"Morten W. Petersen" writes:
> I was working in Python today, and sat there scratching my head as the
> numbers for calculations didn't add up. It went into negative numbers,
> when that shouldn't have been possible.
>
> Turns out I had a very small typo, I had =- instead of -=.
>
> Isn't it unpy
On 14/03/2023 21:28, avi.e.gr...@gmail.com wrote:
TThere are people now trying to in some ways ruin the usability by putting in
type hints that are ignored and although potentially helpful as in a linter
evaluating it, instead often make it harder to read and write code if required
to use it
ourse, freedom is relative and after you have been mugged a few times by your
errors, you may decide it is worth getting some protection.
So, consider having code reviews where fresh eyes may spot your errors.
-Original Message-
From: Python-list On
Behalf Of Morten W. Petersen
Hoi.
After reading the replies, I think some script / linter etc. is the right
thing to do. What's the best linter for Python out there that covers this
as well?
At first glance I thought =- was a new assignment operator, and this is
what seemed unpythonic to me, to have two operators that were s
On 2023-03-13, Morten W. Petersen wrote:
> I was working in Python today, and sat there scratching my head as the
> numbers for calculations didn't add up. It went into negative numbers,
> when that shouldn't have been possible.
>
> Turns out I had a very small typo, I had =- instead of -=.
>
> I
On 3/13/23 17:26, Morten W. Petersen wrote:
It went into negative numbers,
when that shouldn't have been possible.
Turns out I had a very small typo, I had =- instead of -=.
Isn't it unpythonic to be able to make a mistake like that?
That is why I tell Alice it is always best to stay positi
On 3/13/2023 9:47 PM, Chris Angelico wrote:
On Tue, 14 Mar 2023 at 12:38, Thomas Passin wrote:
On 3/13/2023 9:07 PM, Chris Angelico wrote:
Of course, all this is predicated on you actually putting whitespace
around your equals signs. If you write it all crunched together as
"x=-5", there's no
On Tue, 14 Mar 2023 at 12:38, Thomas Passin wrote:
>
> On 3/13/2023 9:07 PM, Chris Angelico wrote:
> > Of course, all this is predicated on you actually putting whitespace
> > around your equals signs. If you write it all crunched together as
> > "x=-5", there's no extra clues to work with.
> >
>
On 3/13/2023 9:07 PM, Chris Angelico wrote:
Of course, all this is predicated on you actually putting whitespace
around your equals signs. If you write it all crunched together as
"x=-5", there's no extra clues to work with.
Linters and code reviewers can make use of all the available
informatio
Morten,
Suggesting something is UNPYTHONIC is really not an argument I take
seriously.
You wrote VALID code by the rules of the game and it is not a requirement
that it guesses at what you are trying to do and calls you an idiot!
More seriously, python lets you do some completely obscure things
On 2023-03-14 00:28, Gary Herron wrote:
On 3/13/23 2:26 PM, morp...@gmail.com wrote:
Hi.
I was working in Python today, and sat there scratching my head as the
numbers for calculations didn't add up. It went into negative numbers,
when that shouldn't have been possible.
Turns out I had a ver
On Tue, 14 Mar 2023 at 11:37, Gary Herron wrote:
>
>
> On 3/13/23 2:26 PM, morp...@gmail.com wrote:
> > Hi.
> >
> > I was working in Python today, and sat there scratching my head as the
> > numbers for calculations didn't add up. It went into negative numbers,
> > when that shouldn't have been p
On 3/13/23 2:26 PM, morp...@gmail.com wrote:
Hi.
I was working in Python today, and sat there scratching my head as the
numbers for calculations didn't add up. It went into negative numbers,
when that shouldn't have been possible.
Turns out I had a very small typo, I had =- instead of -=.
I
To the many who responded, many thanks.
I,too, found Nick Coghlan's answer iluminating.
Mike
--
There are always gossips everywhere you go and few of them
limit themselves to veracity when what they consider a good
story is available to keep their audience entertained.
- MM
--
https://mail
On Sun, May 27, 2018 at 10:36:30AM +1000, Ben Finney wrote:
> Nick also explains that, because the name ‘_’ has too many conventional
> meanings already, the name ‘__’ is better for “don't need this value but
> I am required to specify a name”.
_() is often bound to gettext.gettext() in the globa
Mike McClain writes:
> Steven D'Aprano and Ben Finney used these '_' and '__'.
> Steve said, "[[] for _ in range(5)]".
> Ben said, "[ [] for __ in range(5) ]".
>
> These aren't listed separately in the index
That's right, the names ‘_’ and ‘__’ have no special meaning in
Python-the-language
On 27May2018 09:46, Chris Angelico wrote:
On Sun, May 27, 2018 at 9:40 AM, Thomas Jollans wrote:
There's nothing special about _, it's just a possible name of a
variable, albeit a very short and entirely uninformative one. Normally,
it's not something you'd actually want to name a variable, of
On Sun, May 27, 2018 at 9:40 AM, Thomas Jollans wrote:
> On 27/05/18 01:19, Mike McClain wrote:
>> In their discussion of 'List replication operator'
>> Steven D'Aprano and Ben Finney used these '_' and '__'.
>> Steve said, "[[] for _ in range(5)]".
>> Ben said, "[ [] for __ in range(5) ]".
>>
On 27/05/18 01:19, Mike McClain wrote:
> In their discussion of 'List replication operator'
> Steven D'Aprano and Ben Finney used these '_' and '__'.
> Steve said, "[[] for _ in range(5)]".
> Ben said, "[ [] for __ in range(5) ]".
>
> These aren't listed separately in the index, where migh
On 2017-09-13, Andrej Viktorovich wrote:
> I have done mistake while trying to increment int
>
> i=1
> i=+
>
> this left i unchangeable and I got no error.
I doubt it.
Python 2.7.12 (default, Jan 3 2017, 10:08:10)
[GCC 4.9.4] on linux2
Type "help", "copyright", "credits" or "license" for more
On 13/09/2017 14:25, Andrej Viktorovich wrote:
Hello,
I have done mistake while trying to increment int
i=1
i=+
this left i unchangeable and I got no error. But what =+ means at all?
Did you mean i=+1 ?
This means i is set to the value +1. Usually just written 1.
Try:
i=88
i=+1
and s
On Fri, 29 Jul 2016, 09:20 Steven D'Aprano, wrote:
> I'm not sure that partial is intended as an optimization. It may end up
> saving time by avoiding evaluating arguments, but that's not why it exists.
> It exists to enable the functional programming idiom of partial evaluation
> in a simpler, m
On Fri, 29 Jul 2016 12:23 am, Sivan Greenberg wrote:
> 1. When is the use of functools.partial beneficial? When can it be a
> hindrance? Perhaps it can save on func argument evaluation time when
> creating many invocations for asycn exec?
I'm not sure that partial is intended as an optimization.
On Fri, 29 Jul 2016 12:23 am, Sivan Greenberg wrote:
> Hi All,
>
> First apologies for the rather off topic but I grep'd over the existing
> mailing lists and couldn't find one that's suitable, at least judging by
> the titles.
Too many UNRELATED questions! Split them over separate posts!
Resp
On Sat, May 28, 2011 at 11:31 PM, Nobody wrote:
> Not Python, but:
>
> #define SIX 1 + 5
> #define NINE 8 + 1
> ...
> printf("six times nine is: %d\n", SIX * NINE);
*AWESOME*!! That is brilliant!
DNA FTW.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-lis
On Sun, 22 May 2011 15:39:33 -0700, Tim Roberts wrote:
> That IS funny. Interesting how a careful choice of arugments will fool us.
> One of my favorite math jokes is like that. A teacher asked a student to
> reduce the following fraction:
> 16
>
> 64
>
> He says "all I have to do is
On Sat, May 28, 2011 at 10:27 PM, bch wrote:
> And of course, a programmer cannot tell the difference between
> Halloween and Christmas day.
Well known, of course. But a lot of modern programmers don't speak
octal, they only use another power-of-two base; it's as though
someone's cast a hex on th
On May 23, 11:30 pm, rusi wrote:
> On May 23, 5:30 am, Steven D'Aprano
>
>
> +comp.lang.pyt...@pearwood.info> wrote:
> > On Sun, 22 May 2011 15:39:33 -0700, Tim Roberts wrote:
> > > Stef Mientki wrote:
>
> > >>must of us will not use single bits these days, but at first sight, this
> > >>looks f
On May 23, 5:30 am, Steven D'Aprano wrote:
> On Sun, 22 May 2011 15:39:33 -0700, Tim Roberts wrote:
> > Stef Mientki wrote:
>
> >>must of us will not use single bits these days, but at first sight, this
> >>looks funny :
>
> > a=2
> > b=6
> > a and b
> >>6
> > a & b
> >>2
> >
On 22-May-11 15:23 PM, Stef Mientki wrote:
hello,
must of us will not use single bits these days,
but at first sight, this looks funny :
a=2
b=6
a and b
6
a& b
2
a or b
2
a | b
6
cheers,
Stef
5.2. Boolean Operations — and, or, not
These are the Boolean operations, ordered by ascendi
On Sun, 22 May 2011 15:39:33 -0700, Tim Roberts wrote:
> Stef Mientki wrote:
>>
>>must of us will not use single bits these days, but at first sight, this
>>looks funny :
>>
> a=2
> b=6
> a and b
>>6
> a & b
>>2
> a or b
>>2
> a | b
>>6
>
> That IS funny. Interesting how
On Mon, May 23, 2011 at 8:39 AM, Tim Roberts wrote:
> That IS funny. Interesting how a careful choice of arugments will fool us.
> One of my favorite math jokes is like that. A teacher asked a student to
> reduce the following fraction:
> 16
>
> 64
>
> He says "all I have to do is cancel
Stef Mientki wrote:
>
>must of us will not use single bits these days,
>but at first sight, this looks funny :
>
a=2
b=6
a and b
>6
a & b
>2
a or b
>2
a | b
>6
That IS funny. Interesting how a careful choice of arugments will fool us.
One of my favorite math jokes i
On 5/22/2011 5:57 PM, Thomas 'PointedEars' Lahn wrote:
Stef Mientki wrote:
must of us will not use single bits these days,
but at first sight, this looks funny :
a=2
b=6
a and b
6
a& b
2
a or b
2
a | b
6
Change the order of the operands and see what happens.
or change a,b to 1,2
Stef Mientki wrote:
> must of us will not use single bits these days,
> but at first sight, this looks funny :
>
a=2
b=6
a and b
> 6
a & b
> 2
a or b
> 2
a | b
> 6
Change the order of the operands and see what happens.
--
PointedEars
Bitte keine Kopien per E-Mail
On 2010-09-30, namekuseijin wrote:
> it generates a list from syntax comprehended in list-like syntax!
Okay, help me out here. (Killed the crossposting.)
I am not understanding how the word applies. I'm fine with it, but I don't
see any relation at all between the thing called a list comprehen
On 29 set, 17:46, Xah Lee wrote:
> On Sep 29, 11:02 am, namekuseijin wrote:
>
> > On 28 set, 19:38, Xah Lee wrote:
>
> > > • “list comprehension” is a very bad jargon; thus harmful to
> > > functional programing or programing in general. Being a bad jargon, it
> > > encourage mis-communication,
On Wed, Sep 29, 2010 at 2:46 PM, Xah Lee wrote:
> what's your basis in saying that “list comprehension” is intuitive?
>
> any statics, survery, research, references you have to cite?
>
> to put this in context, are you saying that lambda, is also intuitive?
> “let” is intuitive? “for” is intuitiv
On Sep 29, 11:02 am, namekuseijin wrote:
> On 28 set, 19:38, Xah Lee wrote:
>
> > • “list comprehension” is a very bad jargon; thus harmful to
> > functional programing or programing in general. Being a bad jargon, it
> > encourage mis-communication, mis-understanding.
>
> I disagree: it is a qu
On 28 set, 19:38, Xah Lee wrote:
> • “list comprehension” is a very bad jargon; thus harmful to
> functional programing or programing in general. Being a bad jargon, it
> encourage mis-communication, mis-understanding.
I disagree: it is a quite intuitive term to describe what the
expression does
2010-09-28
On Sep 28, 12:07 pm, namekuseijin wrote:
> On 28 set, 14:56, Xah Lee wrote:
>
> > ultimately, all lang gets transformed at the compiler level to become
> > machine instructions, which is imperative programing in the ultimate
> > sense.
>
> > You say that “do” is merely macro and ultim
xah wrote:
> in anycase, how's “do” not imperative?
On Sep 28, 6:27 am, namekuseijin wrote:
> > how's “do” a “named let”? can you show example or reference of that
> > proposal? (is it worthwhile?)
>
> I'll post it again in the hope you'll read this time:
>
> "
> (do ((i 0 (+ 1 i)) ; i initially
On 27 set, 18:39, Xah Lee wrote:
> On Sep 27, 12:11 pm, namekuseijin wrote:
>
> > On 27 set, 16:06, Xah Lee wrote:> 2010-09-27
>
> > > > For instance, this is far more convenient:
> > > > [x+1 for x in [1,2,3,4,5] if x%2==0]
> > > > than this:
> > > > map(lambda x:x+1,filter(lambda x:x%2==0,[1,2
On Sep 27, 12:11 pm, namekuseijin wrote:
> On 27 set, 16:06, Xah Lee wrote:> 2010-09-27
>
> > > For instance, this is far more convenient:
> > > [x+1 for x in [1,2,3,4,5] if x%2==0]
> > > than this:
> > > map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))
>
> > How about this:
>
> [snip]
>
> h
On 27 set, 16:06, Xah Lee wrote:
> 2010-09-27
>
> > For instance, this is far more convenient:
> > [x+1 for x in [1,2,3,4,5] if x%2==0]
> > than this:
> > map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))
>
> How about this:
[snip]
how about this: read before replying.
--
http://mail.python
2010-09-27
> For instance, this is far more convenient:
> [x+1 for x in [1,2,3,4,5] if x%2==0]
> than this:
> map(lambda x:x+1,filter(lambda x:x%2==0,[1,2,3,4,5]))
How about this:
LC(func, inputList, P)
compared to
[func for myVar in inputList if P]
the functional form is:
• shorter
• n
On 21/09/2010 04:21, Jerry Fleming wrote:
Hi,
Having the following python code:
import locale
import re
locale.setlocale(locale.LC_ALL, 'zh_CN.utf8')
re.findall('(?uL)\s+', u'\u2001\u3000\x20', re.U|re.L)
re.findall('\s+', u'\u2001\u3000\x20', re.U|re.L)
re.findall('(?uL)\s+', u'\u2001\u3000\
Hi,
Having the following python code:
import locale
import re
locale.setlocale(locale.LC_ALL, 'zh_CN.utf8')
re.findall('(?uL)\s+', u'\u2001\u3000\x20', re.U|re.L)
re.findall('\s+', u'\u2001\u3000\x20', re.U|re.L)
re.findall('(?uL)\s+', u'\u2001\u3000\x20')
I was wondering why doesn't it find
well, reloading is the thing which I do most in coding practice :-)
For me its a basic thing like cell proliferation in biology.
I simply never do it. It has subtle issues, one of them you found,
others you say you work around by introducing actual frameworks. But you
might well forget some corn
at that point of comparison the module is already identical ("klass =
getattr(mod, name)")
Ah, didn't know that context.
even more corner-cases. Python's import-mechanism can sometimes be
rather foot-shoot-prone.
still don't see a real reason against the mere module+name comparison.
same iss
On Apr 27, 1:10 pm, Terry Reedy wrote:
> The difference between
>
> hasvowels = lambda x:max([y in x for y in "aeiou"])
>
> and
>
> def hasvowels(x): return max([y in x for y in "aeiou"])
>
> is that the first is 4 chars shorter, but the result has a generic
> .__name__ attribute of '' insteand of
jazbees wrote:
On Apr 25, 12:11 pm, Duncan Booth
wrote:
jazbees wrote:
hasvowels = lambda x:max([y in x for y in "aeiou"])
hasvowels("parsnips")
True
hasvowels("sfwdkj")
False
Do you object to using def to define functions?
Not at all. Do you object to my use of lambdas? I'm not aware
On Apr 27, 11:43 am, jazbees wrote:
> On Apr 25, 12:11 pm, Duncan Booth
> wrote:
>
> > jazbees wrote:
> > hasvowels = lambda x:max([y in x for y in "aeiou"])
> > hasvowels("parsnips")
> > > True
> > hasvowels("sfwdkj")
> > > False
>
> > Do you object to using def to define functio
On Apr 25, 12:11 pm, Duncan Booth
wrote:
> jazbees wrote:
> hasvowels = lambda x:max([y in x for y in "aeiou"])
> hasvowels("parsnips")
> > True
> hasvowels("sfwdkj")
> > False
>
> Do you object to using def to define functions?
Not at all. Do you object to my use of lambdas? I'
Arnaud Delobelle wrote:
return any( not val for val in value_list )
This is the same as:
return not all(value_list)
Yes, I should have remembered De Morgan's Theorem. Thanks!
-John
--
http://mail.python.org/mailman/listinfo/python-list
John Posner writes:
> jazbees wrote:
>
>> I'm surprised to see that the use of min and max for element-wise
>> comparison with lists has not been mentioned. When fed lists of True/
>> False values, max will return True if there is at least one True in
>> the list, while min will return False if
jazbees wrote:
> I'm surprised to see that the use of min and max for element-wise
> comparison with lists has not been mentioned. When fed lists of True/
> False values, max will return True if there is at least one True in
> the list, while min will return False if there is at least one False.
jazbees wrote:
hasvowels = lambda x:max([y in x for y in "aeiou"])
hasvowels("parsnips")
> True
hasvowels("sfwdkj")
> False
>
Do you object to using def to define functions?
Anyway, it is probably clearer to use the builtin 'any' for code like this:
>>> def hasvowels(s):
...
I'm surprised to see that the use of min and max for element-wise
comparison with lists has not been mentioned. When fed lists of True/
False values, max will return True if there is at least one True in
the list, while min will return False if there is at least one False.
Going back to the OP's i
>> Of course dicts and sets are sequences. But there are also sequences
>> on which len doesn't work.
>
> That was my intuition, too. But Python takes a different stance:
It's a sequence if it can be indexed by numbers in range(len(seq)).
Neither dicts nor sets can be indexed that way.
Regards
On Fri, 24 Apr 2009 03:22:50 -0700, Paul Rubin wrote:
> Steven D'Aprano writes:
>> len() works on dicts and sets, and they're not sequences.
>
> Of course dicts and sets are sequences.
Dicts and sets are explicitly described as "other containers":
http://docs.python.org/library/stdtypes.html#s
Paul Rubin wrote:
> Steven D'Aprano writes:
>> len() works on dicts and sets, and they're not sequences.
>
> Of course dicts and sets are sequences. But there are also sequences
> on which len doesn't work.
That was my intuition, too. But Python takes a different stance:
>>> from collections
Steven D'Aprano writes:
> len() works on dicts and sets, and they're not sequences.
Of course dicts and sets are sequences. But there are also sequences
on which len doesn't work.
You could use: sum(1 for x in seq)
Of course iterating through seq may have undesired side effects.
--
http://mail
On Thu, 23 Apr 2009 17:18:25 +0800, Leo wrote:
>> There's also the performance issue. I might have a sequence-like
>> structure where calling len() takes O(N**2) time, (say, a graph) but
>> calling __nozero__ might be O(1). Why defeat the class designer's
>> optimizations?
>
> Is that true?
> Cal
On Fri, 24 Apr 2009 06:50:01 +, Lie Ryan wrote:
> Gerhard Häring wrote:
>> len() make it clear that the argument is a sequence.
>
> Not necessarily.
len() works on dicts and sets, and they're not sequences.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Gerhard Häring wrote:
len() make it clear
that the argument is a sequence.
Not necessarily. Classes that overrides __len__ may fool that assumption
(well, in python classes that overrides special functions may do
anything it is never intended to do).
I often think an "if item:" as "is item
Steven D'Aprano wrote:
On Mon, 20 Apr 2009 15:13:15 -0500, Grant Edwards wrote:
I fail to see the difference between "length greater than 0" and "list
is not empty". They are, by definition, the same thing, aren't they?
For built-in lists, but not necessarily for arbitrary list-like sequenc
Peter Otten <__pete...@web.de> writes:
> The only "popular" data structure I know that implements its length
> like this are strings in C.
Linked lists and trees also tend to do the same, with the exception of
those that explicitly store their length to optimize length queries.
--
http://mail.pyt
Leo wrote:
> Steven D'Aprano wrote:
>
>> On Mon, 20 Apr 2009 15:13:15 -0500, Grant Edwards wrote:
>>
>>
>>> I fail to see the difference between "length greater than 0" and "list
>>> is not empty". They are, by definition, the same thing, aren't they?
>>
>> For built-in lists, but not necessa
Steven D'Aprano wrote:
> On Mon, 20 Apr 2009 15:13:15 -0500, Grant Edwards wrote:
>
>
>> I fail to see the difference between "length greater than 0" and "list
>> is not empty". They are, by definition, the same thing, aren't they?
>
> For built-in lists, but not necessarily for arbitrary list
On 21 Apr 2009 03:06:40 GMT, Steven D'Aprano wrote:
> On Mon, 20 Apr 2009 15:53:41 +, Peter Pearson wrote:
>
>> Like Gerhard, I prefer the construction that explicitly says, "This is a
>> list, and this is what I'll do if it's not empty." To me, and I suspect
>> to a great many programmers, "i
On 2009-04-21, Steven D'Aprano wrote:
> No matter what x is (excluding buggy classes), "if x" means
> "test whether x is true in a boolean context".
>
> If x happens to be a list, that means "x is empty". If x is a
> float, it means "x is positive or negative zero".
I think you've got your true/
On Apr 20, 6:54 pm, Gerhard Häring wrote:
> Peter Otten wrote:
> > bdb112 wrote:
>
> >> Your explanation of Boolean ops on lists was clear.
> >> It leads to some intriguing results:
>
> >> bool([False])
> >> --> True
>
> >> I wonder if python 3 changes any of this?
>
> > No. Tests like
>
> > if it
On Mon, 20 Apr 2009 15:53:41 +, Peter Pearson wrote:
> Like Gerhard, I prefer the construction that explicitly says, "This is a
> list, and this is what I'll do if it's not empty." To me, and I suspect
> to a great many programmers, "if x:" does *not* mean "if x is not
> empty", it means "if
On Tue, 21 Apr 2009 00:32:44 +0200, Gerhard Häring wrote:
> The reason I preferred len(), btw., was only that len() make it clear
> that the argument is a sequence.
>
> Maybe I was just too annoyed by lots of Python code I read that looked
> like this:
>
> def foo(x, y, z):
> if x:
>
On Mon, 20 Apr 2009 15:13:15 -0500, Grant Edwards wrote:
> I fail to see the difference between "length greater than 0" and "list
> is not empty". They are, by definition, the same thing, aren't they?
For built-in lists, but not necessarily for arbitrary list-like sequences.
There's also the p
Gerhard Häring wrote:
Martin v. Löwis wrote:
Are they widespread? I haven't noticed, yet.
I prefer to write it explicitly:
if len(lst) > 0:
I prefer to test explicitly for the truth value of the
list. I don't want to test whether the length of the list
is greater than 0 (in fact, I don't care
> > No. Tests like
>
> > if items:
> > ...
>
> > to verify that items is a non-empty list are a widespread idiom in Python.
> > They rely on the behaviour you observe.
>
> Are they widespread? I haven't noticed, yet.
It's the preferred form (as recommended by PEP 8).
Raymond
--
http://mail.py
Martin v. Löwis wrote:
>> Are they widespread? I haven't noticed, yet.
>>
>> I prefer to write it explicitly:
>>
>> if len(lst) > 0:
>
> I prefer to test explicitly for the truth value of the
> list. I don't want to test whether the length of the list
> is greater than 0 (in fact, I don't care abo
>> I prefer to write it explicitly:
>>
>> if len(lst) > 0:
>>...
>
> At the very least, IMO you should write this as
>
> if len(lst):
> ...
>
> There's no reason to be explicit about the numeric comparison.
I think in the mind-set that dislikes relying on boolean conversion
of lists, re
>> I don't want to test whether the length of the list
>> is greater than 0 [...] - I want to know whether the
>> list is empty (or not empty).
>
> I fail to see the difference between "length greater than 0"
> and "list is not empty". They are, by definition, the same
> thing, aren't they?
Yes,
On 2009-04-20, Martin v. L?wis wrote:
> I don't want to test whether the length of the list
> is greater than 0 [...] - I want to know whether the
> list is empty (or not empty).
I fail to see the difference between "length greater than 0"
and "list is not empty". They are, by definition, the s
In article ,
=?ISO-8859-1?Q?Gerhard_H=E4ring?= wrote:
>
>I prefer to write it explicitly:
>
>if len(lst) > 0:
>...
At the very least, IMO you should write this as
if len(lst):
...
There's no reason to be explicit about the numeric comparison.
--
Aahz (a...@pythoncraft.com) <
> Are they widespread? I haven't noticed, yet.
>
> I prefer to write it explicitly:
>
> if len(lst) > 0:
I prefer to test explicitly for the truth value of the
list. I don't want to test whether the length of the list
is greater than 0 (in fact, I don't care about the length
property of the list
AggieDan04 a écrit :
On Apr 20, 2:03 am, bdb112 wrote:
Is there any obvious reason why
[False,True] and [True,True]
gives [True, True]
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
(Intel)]
X and Y == (Y if X else X)
X or Y == (X if X else Y)
[False, True] is t
Peter Pearson writes:
> The "not empty" interpretation is a cute shortcut. But
> somebody's gotta put up some resistance to cute shortcuts,
> or we'll find ourselves back with Perl.
+ QOTW
--
http://mail.python.org/mailman/listinfo/python-list
On 20 Apr 2009 09:26:34 GMT, Steven D'Aprano wrote:
> On Mon, 20 Apr 2009 10:54:40 +0200, Gerhard Häring wrote:
[snip]
>> I prefer to write it explicitly:
>>
>> if len(lst) > 0:
>
> Do you also count the length of a list explicitly?
>
> n = 0
> for item in lst:
> n += 1
> if n > 0:
> ...
>
On Mon, 20 Apr 2009 10:54:40 +0200, Gerhard Häring wrote:
> Peter Otten wrote:
>> bdb112 wrote:
>>
>>> Your explanation of Boolean ops on lists was clear. It leads to some
>>> intriguing results:
>>>
>>> bool([False])
>>> --> True
>>>
>>> I wonder if python 3 changes any of this?
>>
>> No. Tests
Gerhard Häring wrote:
> Peter Otten wrote:
>> bdb112 wrote:
>>
>>> Your explanation of Boolean ops on lists was clear.
>>> It leads to some intriguing results:
>>>
>>> bool([False])
>>> --> True
>>>
>>> I wonder if python 3 changes any of this?
>>
>> No. Tests like
>>
>> if items:
>>...
>>
On Mon, Apr 20, 2009 at 1:54 AM, Gerhard Häring wrote:
> Peter Otten wrote:
>> bdb112 wrote:
>>
>>> Your explanation of Boolean ops on lists was clear.
>>> It leads to some intriguing results:
>>>
>>> bool([False])
>>> --> True
>>>
>>> I wonder if python 3 changes any of this?
>>
>> No. Tests like
Peter Otten wrote:
> bdb112 wrote:
>
>> Your explanation of Boolean ops on lists was clear.
>> It leads to some intriguing results:
>>
>> bool([False])
>> --> True
>>
>> I wonder if python 3 changes any of this?
>
> No. Tests like
>
> if items:
>...
>
> to verify that items is a non-empty l
bdb112 wrote:
> Your explanation of Boolean ops on lists was clear.
> It leads to some intriguing results:
>
> bool([False])
> --> True
>
> I wonder if python 3 changes any of this?
No. Tests like
if items:
...
to verify that items is a non-empty list are a widespread idiom in Python.
They
THanks Gabriel,
Now I know about the zip function.
Your explanation of Boolean ops on lists was clear.
It leads to some intriguing results:
bool([False])
--> True
I wonder if python 3 changes any of this?
> A and B means: check the boolean value of A; if it's false, return A.
> Else, return B
On Apr 20, 2:03 am, bdb112 wrote:
> Is there any obvious reason why
> [False,True] and [True,True]
> gives [True, True]
>
> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
> (Intel)]
X and Y == (Y if X else X)
X or Y == (X if X else Y)
[False, True] is true, so the and operat
On Aug 22, 5:43 pm, "Medardo Rodriguez (Merchise Group)"
<[EMAIL PROTECTED]> wrote:
> On Fri, Aug 22, 2008 at 6:30 PM, defn noob <[EMAIL PROTECTED]> wrote:
> > What does >> and << do?
>
> Normally they are bitwise operators:>> Shifts bits right
>
> << Shifts bits left
>
> print 1 << 3
> 8
>
> becau
On Fri, Aug 22, 2008 at 6:30 PM, defn noob <[EMAIL PROTECTED]> wrote:
> What does >> and << do?
Normally they are bitwise operators:
>> Shifts bits right
<< Shifts bits left
print 1 << 3
8
because 8 = 1000 in binary
Regards
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, Aug 22, 2008 at 6:30 PM, defn noob <[EMAIL PROTECTED]> wrote:
> What does >> and << do?
>
> Googling on them and they are just ignored...
>
> --
>
http://docs.python.org/lib/bitstring-ops.html
>
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/l
1 - 100 of 116 matches
Mail list logo
