On 2018-05-19 11:38:09 +0300, Marko Rauhamaa wrote:
> "Peter J. Holzer" :
> > (I wonder whether the notion that “=” and “==” are easy to mix up
> > stems from the early days of C when C was an outlier (most other
> > languages at the time used “=” for equality). Now C is mainstream and
> > it's tho
"Peter J. Holzer" :
> (I wonder whether the notion that “=” and “==” are easy to mix up
> stems from the early days of C when C was an outlier (most other
> languages at the time used “=” for equality). Now C is mainstream and
> it's those other languages that seem odd.)
I occasionally mix them up
On 2018-05-16 01:26:38 +0100, bartc wrote:
> On 15/05/2018 21:21, Peter J. Holzer wrote:
> > I have been programming in C since the mid-80's and in Perl since the
> > mid-90's (both languages allow assignment expressions). I accumulated my
> > fair share of bugs in that time, but AFAIR I made this
On 2018-05-16 00:04:06 +, Steven D'Aprano wrote:
> On Tue, 15 May 2018 22:21:15 +0200, Peter J. Holzer wrote:
> > On 2018-05-15 00:52:42 +, Steven D'Aprano wrote:
> [...]
> >> By 1991 there had already been *decades* of experience with C
> >
> > About one and a half decades.
>
> That woul
On Wed, May 16, 2018 at 10:06 AM, bartc wrote:
> On 16/05/2018 16:09, Ian Kelly wrote:
>>
>> On Tue, May 15, 2018, 6:36 PM bartc wrote:
>>
>>> On 16/05/2018 01:04, Steven D'Aprano wrote:
>>>
I'm not a C coder, but I think that specific example would be immune to
the bug we are discussin
On 16/05/2018 16:09, Ian Kelly wrote:
On Tue, May 15, 2018, 6:36 PM bartc wrote:
On 16/05/2018 01:04, Steven D'Aprano wrote:
I'm not a C coder, but I think that specific example would be immune to
the bug we are discussing, since (I think) you can't chain assignments in
C. Am I right?
Assi
On Tue, May 15, 2018, 6:36 PM bartc wrote:
> On 16/05/2018 01:04, Steven D'Aprano wrote:
>
> > I'm not a C coder, but I think that specific example would be immune to
> > the bug we are discussing, since (I think) you can't chain assignments in
> > C. Am I right?
>
> Assignments can be chained in
On Thu, May 17, 2018 at 12:25 AM, Grant Edwards
wrote:
> On 2018-05-16, Steven D'Aprano wrote:
>> On Tue, 15 May 2018 22:21:15 +0200, Peter J. Holzer wrote:
>>
>>> On 2018-05-15 00:52:42 +, Steven D'Aprano wrote:
>> [...]
By 1991 there had already been *decades* of experience with C
>>>
On 2018-05-16, Steven D'Aprano wrote:
> On Tue, 15 May 2018 22:21:15 +0200, Peter J. Holzer wrote:
>
>> On 2018-05-15 00:52:42 +, Steven D'Aprano wrote:
> [...]
>>> By 1991 there had already been *decades* of experience with C
>>
>> About one and a half decades.
>
> That would still be plural
On 16/05/2018 01:04, Steven D'Aprano wrote:
I'm not a C coder, but I think that specific example would be immune to
the bug we are discussing, since (I think) you can't chain assignments in
C. Am I right?
Assignments can be chained in C (with right-to-left precedence) as can
augmented assignm
On 15/05/2018 21:21, Peter J. Holzer wrote:
I have been programming in C since the mid-80's and in Perl since the
mid-90's (both languages allow assignment expressions). I accumulated my
fair share of bugs in that time, but AFAIR I made this particular error
very rarely (I cannot confidently cla
On Tue, 15 May 2018 22:21:15 +0200, Peter J. Holzer wrote:
> On 2018-05-15 00:52:42 +, Steven D'Aprano wrote:
[...]
>> By 1991 there had already been *decades* of experience with C
>
> About one and a half decades.
That would still be plural decades.
C's first release was 1972, so more like
On 2018-05-15 00:52:42 +, Steven D'Aprano wrote:
> Now remember that in 1991 when Guido made the decision to ban = as an
> expression, those concepts didn't even exist. There were no Python
> linters, and no reason to imagine that there ever would be. Guido didn't
> know that Python would be
On Tue, May 15, 2018 at 12:52:42AM +, Steven D'Aprano wrote:
> But you miss the point that even if = versus == errors are picked up by
> code reviews or tests, they are still software bugs. Your *process*
> (testing and reviews) picked up the bug before they went into production,
> but *the
On Mon, 14 May 2018 21:24:01 -0400, Dennis Lee Bieber wrote:
> The problem with adding the feature is that it will start to be
> used by
> newbies who lack the discipline to use it reliably: ensuring that
> comparisons are coded with constants (which for Python really means
> literals) on t
On Mon, 14 May 2018 18:20:13 -0500, Python wrote:
> I am hardly perfect.
Have you tried just wanting to be perfect more?
Look, we get it: it is possible to improve the quality of your code by
paying attention to what you do, by proof-reading, testing, code reviews,
warnings, linters, etc. We'
On Tue, May 15, 2018 at 9:20 AM, Python wrote:
> I'm well acquainted with that pheonomenon, though I daresay that if
> you proofread your own product you will often find your mistakes. You
> just won't always. But, I never said review it right after you wrote
> it, and in fact I don't do that (w
On Mon, May 14, 2018 at 12:02:47PM -0600, Ian Kelly wrote:
> On Mon, May 14, 2018 at 9:38 AM, Python wrote:
> > Absolutely correct. If you're not doing THOROUGH code reviews, and
> > not thoroughly testing your code, your job is only half done. You
> > should be your own first reviewer, and then
On Mon, May 14, 2018 at 9:38 AM, Python wrote:
> Absolutely correct. If you're not doing THOROUGH code reviews, and
> not thoroughly testing your code, your job is only half done. You
> should be your own first reviewer, and then have a second someone
> competent review it after you do.
One sho
On Mon, May 14, 2018 at 9:20 AM, Python wrote:
> On Sun, May 13, 2018 at 02:42:48PM +1000, Chris Angelico wrote:
>> On Sun, May 13, 2018 at 2:31 PM, Python wrote:
>> >> Yes, and I'd go further: I *am* too stupid to get this right.
>> >
>> > No, you are not. Do you ever say "dog" when you mean "d
On Mon, 14 May 2018 10:20:06 -0500, Python wrote:
> Preventing *certain classes* of bugs, mainly botching syntax, is mostly
> just a matter of wanting to,
That comment is very ignorant of the mental processes involved in both
language processing and typing, two skills used in programming. You c
On Sun, May 13, 2018 at 09:46:48PM +1000, Chris Angelico wrote:
> > I expect that these days it will be rare, since most C compilers would
> > default to warning about it if you run with warnings enabled.
>
> That assumes that you regularly run with warnings enabled. While that
> might seem like a
On Sun, May 13, 2018 at 11:05:48AM +, Steven D'Aprano wrote:
> On Sat, 12 May 2018 21:42:13 -0500, Python wrote:
>
> > Responding to this further would essentially just require me to
> > reiterate what I already wrote--I won't do that. I'll simply maintain
> > that in my rather lenghty experi
On Sun, May 13, 2018 at 02:42:48PM +1000, Chris Angelico wrote:
> On Sun, May 13, 2018 at 2:31 PM, Python wrote:
> >> Yes, and I'd go further: I *am* too stupid to get this right.
> >
> > No, you are not. Do you ever say "dog" when you mean "dot" instead?
> > Do you ever say "dad" when you mean "
On Mon, May 14, 2018 at 10:49 PM, Rhodri James wrote:
> On 13/05/18 05:31, Python wrote:
>>
>> No, you are not. Do you ever say "dog" when you mean "dot" instead?
>> Do you ever say "dad" when you mean "mom" instead?
>
>
> One of my aunts used to muddle family names all the time. She once called
On 13/05/18 05:31, Python wrote:
No, you are not. Do you ever say "dog" when you mean "dot" instead?
Do you ever say "dad" when you mean "mom" instead?
One of my aunts used to muddle family names all the time. She once
called me by my sister's name; one would have thought the beard was a
cl
On Sun, May 13, 2018 at 9:05 PM, Steven D'Aprano
wrote:
> On Sat, 12 May 2018 21:42:13 -0500, Python wrote:
>
>> Responding to this further would essentially just require me to
>> reiterate what I already wrote--I won't do that. I'll simply maintain
>> that in my rather lenghty experience, this m
On Sat, 12 May 2018 21:42:13 -0500, Python wrote:
> Responding to this further would essentially just require me to
> reiterate what I already wrote--I won't do that. I'll simply maintain
> that in my rather lenghty experience, this mistake has actually been
> rather rare and has to my knowledge
On Sun, May 13, 2018 at 2:31 PM, Python wrote:
> On Wed, May 09, 2018 at 03:57:35PM +1000, Chris Angelico wrote:
>> On Wed, May 9, 2018 at 3:44 PM, Steven D'Aprano
>> > If all programmers were as awesome as you and never made typos, the world
>> > would be a better place. But we know from experien
On Wed, May 09, 2018 at 03:57:35PM +1000, Chris Angelico wrote:
> On Wed, May 9, 2018 at 3:44 PM, Steven D'Aprano
> > If all programmers were as awesome as you and never made typos, the world
> > would be a better place. But we know from experience that even
> > experienced C programmers can make t
On Wed, May 09, 2018 at 05:44:57AM +, Steven D'Aprano wrote:
> > On Tue, May 08, 2018 at 12:45:29AM +, Steven D'Aprano wrote:
> >> Currently, the real reason is that lambda expressions are limited to a
> >> single expression as the body of the function, and binding operations
> >> in Python
On Sun, May 13, 2018 at 01:01:04PM +1000, Chris Angelico wrote:
> That's fine. Your experience has been that it hasn't been a problem;
> other people's experience has been the opposite. I have never
> personally had to deal with bugs in C code where braces are omitted
> and multiple lines indented.
Drat, missed the main point I wanted to address in my last post:
On Tue, May 08, 2018 at 11:36:06PM -0600, Ian Kelly wrote:
> > This example also is a case FOR allowing assignments to be
> > expressions. If Python allowed them, you could rewrite this as:
> >
> >while not (flag = we_are_done()
On Sun, May 13, 2018 at 12:42 PM, Python wrote:
> On Wed, May 09, 2018 at 12:46:07PM -0400, Dennis Lee Bieber wrote:
>> On Tue, 8 May 2018 22:48:52 -0500, Python
>> >if spam == arg:
>>
>> Mis-typing that as
>>
>> if spam = arg:
>>
>> IS the problem -- you've just changed the value
On Tue, May 08, 2018 at 11:36:06PM -0600, Ian Kelly wrote:
> On Tue, May 8, 2018 at 9:48 PM, Python wrote:
> > I'll give you an example that is both a case where Python's design
> > choices make creating a bug easier, AND a case where allowing
> > assignments to be expressions would save you.
> >
On Wed, May 09, 2018 at 03:09:18PM +1000, Chris Angelico wrote:
> On Wed, May 9, 2018 at 1:48 PM, Python wrote:
[much snippage...]
> > flag = (spam == arg)
>
> That's not "side effects only".
Yeah, I'll chalk that up to posting too late in the evening after
working too long a day...
On We
On Sat, May 12, 2018 at 1:03 AM, Ian Kelly wrote:
> On Fri, May 11, 2018 at 7:40 AM, Chris Angelico wrote:
>> So, yes, your function's name is outright lying. But there's nothing
>> about it that is *pretending* to be a normal function. It IS a normal
>> function.
>
> The detail of whether it's a
On Fri, May 11, 2018 at 7:40 AM, Chris Angelico wrote:
> So, yes, your function's name is outright lying. But there's nothing
> about it that is *pretending* to be a normal function. It IS a normal
> function.
The detail of whether it's a generator function affects the function's
execution and ma
On Fri, May 11, 2018 at 11:31 PM, Ian Kelly wrote:
> On Fri, May 11, 2018 at 1:01 AM, Chris Angelico wrote:
>> On Fri, May 11, 2018 at 12:38 PM, Ian Kelly wrote:
>>> Would you also contend that generator functions are wrong because they
>>> pretend to be normal functions?
>>>
>>> def totally_not
On Fri, May 11, 2018 at 11:28 PM, Ian Kelly wrote:
> You can get rid of the while loop:
>
> for x in iter(get_item, None):
> process(x)
>
> The reason I suggested the function I did is because the x in that
> case can't reasonably be turned into an iterator because the logic
> depends on the l
On Fri, May 11, 2018 at 1:01 AM, Chris Angelico wrote:
> On Fri, May 11, 2018 at 12:38 PM, Ian Kelly wrote:
>> Would you also contend that generator functions are wrong because they
>> pretend to be normal functions?
>>
>> def totally_not_a_generator(n):
>> while True:
>> if n % 2 ==
On Fri, May 11, 2018 at 1:06 AM, Chris Angelico wrote:
> On Fri, May 11, 2018 at 4:54 PM, Ian Kelly wrote:
>> On Thu, May 10, 2018 at 11:45 PM, Steven D'Aprano
>> wrote:
>>> To be honest, I'm having trouble thinking of a good use-case for "while
>>> True", now that we have infinite iterators. Mo
Chris Angelico :
> On Fri, May 11, 2018 at 7:10 PM, Gregory Ewing
> wrote:
>> I suggest adding a new builtin constant:
>>
>>YouFeelLikeIt = True
>>
>> Then all pseudo-infinite loops can be written
>>
>>while YouFeelLikeIt:
>> ...
>>
>
> Personally, I prefer to use string literals.
>
On Fri, May 11, 2018 at 7:10 PM, Gregory Ewing
wrote:
> I suggest adding a new builtin constant:
>
>YouFeelLikeIt = True
>
> Then all pseudo-infinite loops can be written
>
>while YouFeelLikeIt:
> ...
>
Personally, I prefer to use string literals.
while "you feel like it":
...
I suggest adding a new builtin constant:
YouFeelLikeIt = True
Then all pseudo-infinite loops can be written
while YouFeelLikeIt:
...
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Marko Rauhamaa wrote:
I was mildly amused when Python happily executed such code. "..." is a
valid expression and thus, a valid statement.
Fortunately, "?" still works for this!
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, May 11, 2018 at 12:03 AM, Steven D'Aprano
wrote:
> On Thu, 10 May 2018 20:38:39 -0600, Ian Kelly wrote:
>
>> Would you also contend that generator functions are wrong because they
>> pretend to be normal functions?
>
> You're going to need to be more specific. In what way are they not norm
On Fri, May 11, 2018 at 4:54 PM, Ian Kelly wrote:
> On Thu, May 10, 2018 at 11:45 PM, Steven D'Aprano
> wrote:
>> To be honest, I'm having trouble thinking of a good use-case for "while
>> True", now that we have infinite iterators. Most cases of
>>
>> while True:
>> x = get_item()
>>
On Fri, May 11, 2018 at 12:38 PM, Ian Kelly wrote:
> Would you also contend that generator functions are wrong because they
> pretend to be normal functions?
>
> def totally_not_a_generator(n):
> while True:
> if n % 2 == 0:
> n //= 2
> else:
> n = n * 3
On Thu, May 10, 2018 at 11:45 PM, Steven D'Aprano
wrote:
> To be honest, I'm having trouble thinking of a good use-case for "while
> True", now that we have infinite iterators. Most cases of
>
> while True:
> x = get_item()
> if not x: break
> process(x)
>
> are better
On Thu, May 10, 2018 at 11:17 PM, Steven D'Aprano
wrote:
> To answer your question from a later post:
>
> In what way does "while True" in the general case pretend
> to be an infinite loop?
>
> It doesn't *pretend* to be an infinite loop. It *is* an infinite loop
> which breaks out early.
On Thu, 10 May 2018 20:38:39 -0600, Ian Kelly wrote:
> Would you also contend that generator functions are wrong because they
> pretend to be normal functions?
You're going to need to be more specific. In what way are they not normal
functions? You call them like normal functions, providing argu
On Fri, 11 May 2018 05:17:59 +, Steven D'Aprano wrote:
> On Fri, 11 May 2018 03:29:57 +0300, Marko Rauhamaa wrote:
[...]
> To answer your question from a later post:
>
> In what way does "while True" in the general case pretend to be an
> infinite loop?
Oops, sorry, that was Ian Kell
On Fri, 11 May 2018 01:51:47 +0300, Marko Rauhamaa wrote:
> Paul Rubin :
>
>> Marko Rauhamaa writes:
>>> It turns out "while True" is the most natural choice in about half of
>>> the while loops.
>>
>> Maybe the rest would be "repeat until" if Python had that?
>
> No. "Repeat until" is a relati
On Fri, 11 May 2018 03:29:57 +0300, Marko Rauhamaa wrote:
>> Now do you understand what I mean about putting the condition into the
>> loop header?
>
> Thanks, but no thanks. The "while True" idiom beats that one hands down.
Why do you think it is better to lie to the reader and tell them they a
On Thu, 10 May 2018 22:59:03 +0300, Marko Rauhamaa wrote:
> It turns out "while True" is the most natural choice in
> about half of the while loops.
YMMV.
In my case, it is more like about one in ten.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, May 10, 2018 at 7:10 PM, Chris Angelico wrote:
> On Fri, May 11, 2018 at 10:29 AM, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> But for the loop itself, you absolutely CAN write this more logically.
>>> I'll take your second version as a template:
>>>
>>> def split_cmd(self, cmd):
On Tue, May 8, 2018 at 11:50 PM, Chris Angelico wrote:
> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly wrote:
>>
>> while True:
>> if we_are_done():
>> break
>> # do some stuff
>> ...
>> if error_occurred():
>> break
>> notify_user()
>>
>>
>> Fixed, using idiomatic Pyt
On Fri, May 11, 2018 at 10:29 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> But for the loop itself, you absolutely CAN write this more logically.
>> I'll take your second version as a template:
>>
>> def split_cmd(self, cmd):
>> args = []
>> while (match := self.TERM_PTN.m
Chris Angelico :
> But for the loop itself, you absolutely CAN write this more logically.
> I'll take your second version as a template:
>
> def split_cmd(self, cmd):
> args = []
> while (match := self.TERM_PTN.match(cmd)) is not None:
> args.append(match.group('ter
On Fri, May 11, 2018 at 8:49 AM, Marko Rauhamaa wrote:
> def split_cmd(self, cmd):
> args = []
> while True:
> match = self.TERM_PTN.match(cmd)
> if match is None:
> return None, None
> args.append(match.group('term'))
>
Paul Rubin :
> Marko Rauhamaa writes:
>> It turns out "while True" is the most natural choice in about half of
>> the while loops.
>
> Maybe the rest would be "repeat until" if Python had that?
No. "Repeat until" is a relatively infrequent need.
Marko
--
https://mail.python.org/mailman/listin
Chris Angelico :
> On Fri, May 11, 2018 at 5:59 AM, Marko Rauhamaa wrote:
>> Joking aside, to answer Chris's question, of course you can use a
>> real condition with "while". However, you shouldn't force it or try
>> to avoid "while True". It turns out "while True" is the most natural
>> choice in
On Wed, 09 May 2018 12:51:15 -0700, Paul Rubin wrote:
> Dennis Lee Bieber writes:
>> Yes, code reviews may catch such errors... and later, when the
>> summary of errors is analyzed for suggestions on how to reduce them --
>> the odds are good that "assignment expressions" will be banned in th
On Fri, May 11, 2018 at 5:59 AM, Marko Rauhamaa wrote:
> Mikhail V :
>
>> On Wed, May 9, 2018 at 8:50 AM, Chris Angelico wrote:
>>> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly wrote:
while True:
>>>
>>> Why is it that "while True" is idiomatic Python for a non-infinite
>>> loop? Is it merely
Mikhail V :
> On Wed, May 9, 2018 at 8:50 AM, Chris Angelico wrote:
>> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly wrote:
>>> while True:
>>
>> Why is it that "while True" is idiomatic Python for a non-infinite
>> loop? Is it merely because Python currently has no other way to spell
>> certain loo
On Wed, May 9, 2018 at 8:50 AM, Chris Angelico wrote:
> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly wrote:
>>
>> while True:
>> if we_are_done():
>> break
>> # do some stuff
>> ...
>> if error_occurred():
>> break
>> notify_user()
>>
>>
>> Fixed, using idiomatic Pyth
On 05/10/2018 03:02 AM, bartc wrote:
On 10/05/2018 09:09, Marko Rauhamaa wrote:
bartc :
When typing in code (in various languages), I have a habit of typing
"..." at places that need to be implemented. For example:
if count:
...
else:
do_something_smart()
b
bartc :
> I wondered what it meant, so I typed in:
>
>print (...)
>
> and it displayed:
>
>Ellipsis
>
> which wasn't very enlightening.
It doesn't mean anything for Python. It's just a special singleton
sentinel object that is stored in the predefined variable "Ellipsis" and
has a literal
On 10/05/2018 09:09, Marko Rauhamaa wrote:
bartc :
On 09/05/2018 06:44, Steven D'Aprano wrote:
But by the time 1.4 came around, Guido had settled on a clean separation
between statements and expressions as part of Python's design.
That separation has gradually weakened over the years,
Presum
Marko wrote:
> When typing in code (in various languages), I have a habit of typing
> "..." at places that need to be implemented
Quite a research area actually
https://wiki.haskell.org/GHC/Typed_holes
--
https://mail.python.org/mailman/listinfo/python-list
bartc :
> On 09/05/2018 06:44, Steven D'Aprano wrote:
>> But by the time 1.4 came around, Guido had settled on a clean separation
>> between statements and expressions as part of Python's design.
>>
>> That separation has gradually weakened over the years,
>
> Presumably it's non-existent now, as i
On Wed, 09 May 2018 22:48:42 +0100, bartc wrote:
> On 09/05/2018 06:44, Steven D'Aprano wrote:
>> On Tue, 08 May 2018 22:48:52 -0500, Python wrote:
>>
>>
>> But by the time 1.4 came around, Guido had settled on a clean
>> separation between statements and expressions as part of Python's
>> desig
On 09/05/2018 06:44, Steven D'Aprano wrote:
On Tue, 08 May 2018 22:48:52 -0500, Python wrote:
But by the time 1.4 came around, Guido had settled on a clean separation
between statements and expressions as part of Python's design.
That separation has gradually weakened over the years,
Presu
On 09/05/18 06:57, Chris Angelico wrote:
On Wed, May 9, 2018 at 3:44 PM, Steven D'Aprano
wrote:
On Tue, 08 May 2018 22:48:52 -0500, Python wrote:
I've always felt that this mentality was insulting to the programmer:
"You're too stupid to get this right." Sure, I've created that bug in
other l
On Wed, May 9, 2018 at 3:44 PM, Steven D'Aprano
wrote:
> On Tue, 08 May 2018 22:48:52 -0500, Python wrote:
>> I've always felt that this mentality was insulting to the programmer:
>> "You're too stupid to get this right." Sure, I've created that bug in
>> other languages (or rather its inverse) b
On Wed, May 9, 2018 at 3:36 PM, Ian Kelly wrote:
>
> while True:
> if we_are_done():
> break
> # do some stuff
> ...
> if error_occurred():
> break
> notify_user()
>
>
> Fixed, using idiomatic Python and without needing to use assignment in
> an expression.
Why is
On Tue, 08 May 2018 22:48:52 -0500, Python wrote:
> On Tue, May 08, 2018 at 12:45:29AM +, Steven D'Aprano wrote:
>> Currently, the real reason is that lambda expressions are limited to a
>> single expression as the body of the function, and binding operations
>> in Python are statements.
>
>
On Tue, May 8, 2018 at 9:48 PM, Python wrote:
> On Tue, May 08, 2018 at 12:45:29AM +, Steven D'Aprano wrote:
>> since = in a statement on its own is not dangerous. People *almost never*
>> intend to write == for the side-effects only:
>
> Seriously? I do this--not every day, but more than occ
On Wed, May 9, 2018 at 1:48 PM, Python wrote:
>> since = in a statement on its own is not dangerous. People *almost never*
>> intend to write == for the side-effects only:
>
> Seriously? I do this--not every day, but more than occasionally, not
> just in Python.
>
> flag = (spam == arg)
> vs.
On Tue, May 08, 2018 at 12:45:29AM +, Steven D'Aprano wrote:
> Currently, the real reason is that lambda expressions are limited to a
> single expression as the body of the function, and binding operations in
> Python are statements.
...which begs the question, why shouldn't assignments be
On Mon, 07 May 2018 22:27:22 +0200, all-lists wrote:
> Hi,
>
> I was wondering (and have asked on StackOverflow [1] in a more elaborate
> way) whether there is a deeper reason to not allow assignments in lambda
> expressions.
Currently, the real reason is that lambda expressions are limited to a
Chris Angelico (2018-May-08, excerpt):
> What exactly would be the scope of the assigned name?
Yes, that's more like the kind of answer I was seeking. But I'm not
entirely satisfied.
> def sort_func(item):
> date = parse_date(item.creation_date)
> return date.day_of_week, date.year, date
On Tue, May 8, 2018 at 6:27 AM, wrote:
> Hi,
>
> I was wondering (and have asked on StackOverflow [1] in a more
> elaborate way) whether there is a deeper reason to not allow
> assignments in lambda expressions.
>
> I'm not criticising, I'm asking in order to know ;-)
>
> The surface-reason is th
84 matches
Mail list logo
