at wrote:
> Dear Carl,
>
> Well, all I can say that for me as a user it would make sense...
>
> Curiosity: in what sense is it redundant?
> All solution/workarounds I have seen so far involve creation of new lists
> (subsets) adding to more processing/computation/memory usage. Redundant
> suggest
In <[EMAIL PROTECTED]>, Gabriel
Genellina wrote:
> Be aware that map, filter, and reduce may be dropped in Python 3000.
> http://www.artima.com/weblogs/viewpost.jsp?thread=98196
> (and I won't miss them if gone)
There are `imap` and `ifilter` in the `itertools` module. I guess/hope
they will sta
At Friday 15/12/2006 06:51, mystilleef wrote:
This why I prefer functional programming constructs for my
list/sequence processing needs.
is_true = lambda x: x > 0
map(process_list, filter(is_true, [-2, -1, 0, 1, 2, 3, 4]))
This why I prefer functional programming constructs for my
list/sequence processing needs.
is_true = lambda x: x > 0
map(process_list, filter(is_true, [-2, -1, 0, 1, 2, 3, 4]))
at wrote:
> With the current Python syntax, I can create for every two lines of code a
> dozen alternative implementations:
The "one way to do it" rule seems to be widely misquoted
and misunderstood.
Of course any Turing-complete programming language is
going to provide infinitely many ways of e
at wrote:
> I think by approving
>
> a = b if condition else c
Again, this allows something to be written as an
expression that formerly could only be written as
a statement, which is a much bigger gain than just
crunching two statements into one.
--
Greg
--
http://mail.python.org/mailman/list
at wrote:
> I am not claiming that it was THE motivation, but it solves my problem...
So we're back to where we started. Look, this "it makes sense for ME",
"it solves MY problem" stuff is just not going to cut it. A language
change is something everyone has to live with, therefore it has to mak
I am not claiming that it was THE motivation, but it solves my problem...
Carl Banks wrote:
>
> at wrote:
>> By the way,
>>
>> I think by approving
>>
>> a = b if condition else c
>>
>> used to avloind
>>
>> if condition:
>> a = b
>> else:
>> a = c
>>
>> which is dealing with sam
Dear Duncan,
Points taken. Its just a workaround for a specific case, I know. Maybe I
just love the elegance of
new_list = [x for x in some_list if some_cond]
and like to see it extended...
I got I nice tip on generators however which would allow me to something
similar without consumin
Dear Diez,
True, I was just mentioning a workaround for a typical case.
Kind regards,
Arjan
Diez B. Roggisch wrote:
>> Is it redundant according to your criteria, yes I would say:
>>
>> a = {True: a, False: c}[condition]
>>
>> or
>>
>> a = [c, a][condition]
>>
>> would yield exactly the sa
at wrote:
> By the way,
>
> I think by approving
>
> a = b if condition else c
>
> used to avloind
>
> if condition:
> a = b
> else:
> a = c
>
> which is dealing with same psychological problem, Guido also recognizes some
> need...
If you think that this change was made for "psych
at wrote:
> I think by approving
>
> a = b if condition else c
>
> used to avloind
>
> if condition:
>a = b
> else:
>a = c
>
> which is dealing with same psychological problem, Guido also recognizes some
> need...
GvR did not introduce the new conditional syntax because he felt
> Is it redundant according to your criteria, yes I would say:
>
> a = {True: a, False: c}[condition]
>
> or
>
> a = [c, a][condition]
>
> would yield exactly the same even in one sentence
Obviously it is _not_ the exact same.
def fac(n):
return n * fac(n-1) if n else 1
Try that wit
at <[EMAIL PROTECTED]> wrote:
> By the way,
>
> I think by approving
>
> a = b if condition else c
>
> used to avloind
>
> if condition:
> a = b
> else:
> a = c
Neither of those is much of an improvement over the other, and in fact if
b or c are complex expressions I would de
Hi Paul,
I appreciate your explanation!
Thanx
@
Paul Rubin wrote:
> at <[EMAIL PROTECTED]> writes:
>> > for x in (x for x in [-2, -1, 0, 1, 2, 3, 4] if x > 0):
>> >... more code ...
>
>> Do you know if this generates a new list internally (memory consumption?)
>
> It does not. Th
By the way,
I think by approving
a = b if condition else c
used to avloind
if condition:
a = b
else:
a = c
which is dealing with same psychological problem, Guido also recognizes some
need...
Is it redundant according to your criteria, yes I would say:
a = {True: a, False: c}
at wrote:
> Carl Banks wrote:
>
> > at wrote:
> >> Well, all I can say that for me as a user it would make sense...
> >
> > Which is, like, step one out of a hundred for getting a syntax change
> > into the language.
> >
> >> Curiosity: in what sense is it redundant?
> >
> > It creates syntactical
at <[EMAIL PROTECTED]> writes:
> > for x in (x for x in [-2, -1, 0, 1, 2, 3, 4] if x > 0):
> >... more code ...
> Do you know if this generates a new list internally (memory consumption?)
It does not. That parenthesized expression is a called generator
expression. It compiles to a sma
Hi Greg,
Well point is that the condition is the only thing happening and does not
really apply to the indented code section, but basically to the list used
in the indented code section.
When I read this code back its like, 'oh we use this list' and by the if
some_condition the next thing I think
Thanx Paul!
Do you know if this generates a new list internally (memory consumption?)
@
Paul Rubin wrote:
> at <[EMAIL PROTECTED]> writes:
>> You proposal, seems nice to me but it doesn't work with Python 2.4.3,
>> should it work with 2.5?
>>
>> Again I am just wondering if the approach for
>
My comments below.
Kind regards,
@
Carl Banks wrote:
> at wrote:
>> Well, all I can say that for me as a user it would make sense...
>
> Which is, like, step one out of a hundred for getting a syntax change
> into the language.
>
>> Curiosity: in what sense is it redundant?
>
> It creates sy
at wrote:
> It is not the addional line containing 'if x > 0:' that bothers me, but the
> additional indentation.
I don't find the additional indentation bothersome.
In fact I think it's helpful, because it makes it
obvious that there is something else going on besides
just a loop.
--
Greg
--
h
at <[EMAIL PROTECTED]> writes:
> You proposal, seems nice to me but it doesn't work with Python 2.4.3, should
> it work with 2.5?
>
> Again I am just wondering if the approach for
>
> [x for c x in some_list if some_condition]
>
> and
> x = a if b else c
>
> could be generalize
at wrote:
> Well, all I can say that for me as a user it would make sense...
Which is, like, step one out of a hundred for getting a syntax change
into the language.
> Curiosity: in what sense is it redundant?
It creates syntactical support for two different ways to do something.
If your plan we
Dear Carl,
Well, all I can say that for me as a user it would make sense...
Curiosity: in what sense is it redundant?
All solution/workarounds I have seen so far involve creation of new lists
(subsets) adding to more processing/computation/memory usage. Redundant
suggests that you know alternativ
No offense, but my conclusions from your mail is that readability is a
matter of taste.
My brains need to process a whole lot more information with your solution
than in my proposal...
but I read somewhere else that GvR rejected the proposal :-(
Ciao,
@
[EMAIL PROTECTED] wrote:
> The propose
at wrote:
> I am not looking for a work around but more interest if other people might
> judge this syntax would come in handy?
Of course people have expressed interest in this in the past, but it's
not going to happen. There's a way to nest for and if statements, and
a different way to nest for
The proposed solution impairs readability because there's a "surprise"
at the end. List comprehensions already open the language up to
readability abuse. Lets not add more.
To avoid the unwanted indentation, I would go with the already
suggested "if not x>0: continue" solution or else something
"at" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> More pythonic in view would be:
>
> for x in [-2, -1, 0, 1, 2, 3, 4] if x > 0:
>... more code ...
Already proposed by someone and rejected by GvR.
--
http://mail.python.org/mailman/listinfo/python-list
> I just need to get work done and I see this type of conditional iteration
> showing up many times obscuring my code because of the additional
> indentation.
Me too. When I don't like the additional indentation I usually have:
if not condition: continue
at the beginning of the bl
Forget 'pythonic'.
I just need to get work done and I see this type of conditional iteration
showing up many times obscuring my code because of the additional
indentation.
In line with previous syntax improvements made in Python my proposal (or
obvious variants) seems a logical next st
You proposal, seems nice to me but it doesn't work with Python 2.4.3, should
it work with 2.5?
Again I am just wondering if the approach for
[x for c x in some_list if some_condition]
and
x = a if b else c
could be generalized for normal straight forward iterations:
for x in s
On 13 Dec 2006 07:47:23 -0800, Paul Rubin
<"http://phr.cx"@nospam.invalid> wrote:
> at <[EMAIL PROTECTED]> writes:
> > I have a lot times the following code:
> >
> > for x in [-2, -1, 0, 1, 2, 3, 4]:
> > if x > 0:
> > ... more code...
>
> Use:
>
> for x in (x in [-2, -1, 0,
at <[EMAIL PROTECTED]> writes:
> I have a lot times the following code:
>
> for x in [-2, -1, 0, 1, 2, 3, 4]:
> if x > 0:
> ... more code...
Use:
for x in (x in [-2, -1, 0, 1, 2, 3, 4] if x > 0):
... more code ...
--
http://mail.python.org/mailman/listinfo/python-
On 2006-12-13, Roberto Bonvallet <[EMAIL PROTECTED]> wrote:
> at wrote:
>> More pythonic in view would be:
>>
>> for x in [-2, -1, 0, 1, 2, 3, 4] if x > 0:
>>... more code ...
>
> Pythonic? Do you realize that Python hasn't even adopted
> well-known statements like 'switch' and 'do while'
at wrote:
> More pythonic in view would be:
>
> for x in [-2, -1, 0, 1, 2, 3, 4] if x > 0:
>... more code ...
Pythonic? Do you realize that Python hasn't even adopted well-known
statements like 'switch' and 'do while' because they would be redundant?
This could be more convenient to you
at wrote:
> THE PROBLEM
>
> I have a lot times the following code:
>
> for x in [-2, -1, 0, 1, 2, 3, 4]:
> if x > 0:
> ... more code...
>
>
> It is not the addional line containing 'if x > 0:' that bothers me, but the
> additional indentation.
for x in ...:
if not x
I would like to spark the discussion about the following syntax problem I
encounter.
THE PROBLEM
I have a lot times the following code:
for x in [-2, -1, 0, 1, 2, 3, 4]:
if x > 0:
... more code...
It is not the addional line containing 'if x > 0:' that bothers me, but
38 matches
Mail list logo
