A few comments come to mind about this discussion about TCO.
First, TCO, Tail Call Optimization, is talking about something that is
an optimization.
Optimizations, are generally some OPTIONAL improvement in the method of
executing the code that doesn't alter its DEFINED meaning.
First big point,
Op 15/08/20 om 15:02 schreef Chris Angelico:
> On Sat, Aug 15, 2020 at 10:45 PM Antoon Pardon
> wrote:
>>
>>
>> I don't understand this argument. The trace back information that is
>> destroyed with this optimization, is information that isn't available
>> anyway if you write the code in an iterat
@Chris: you're very right, but, I repeat, you can't have a real TCO
(asyncio apart):
(venv_3_10) marco@buzz:~$ python
Python 3.10.0a0 (heads/master-dirty:ba18c0b13b, Aug 14 2020, 17:52:45)
[GCC 10.1.1 20200718] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def
On Sat, Aug 15, 2020 at 10:45 PM Antoon Pardon
wrote:
>
> Op 7/08/20 om 18:45 schreef Chris Angelico:
> > On Sat, Aug 8, 2020 at 2:21 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >>
> >> On 2020-08-07 at 17:55:45 +0200,
> >> Marco Sulla wrote:
> >>> @Chris: note that "real" recursion in Pytho
Op 7/08/20 om 18:45 schreef Chris Angelico:
> On Sat, Aug 8, 2020 at 2:21 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>>
>> On 2020-08-07 at 17:55:45 +0200,
>> Marco Sulla wrote:
>>> @Chris: note that "real" recursion in Python is not possible, since
>>> there's no support for tail recursion. M
Christian Seberino wrote:
> A beginner I think could learn Lisp much faster than Python.
For talented beginners, Lisp rocks much like Python, in that easy assignments
are easy enough to implement. On the high end, Lisp rocks again: Lisp masters
are astonishingly productive. In between, beyond pe
On Tue, Aug 11, 2020 at 5:48 AM Roel Schroeven wrote:
> I'm not saying there is nothing useful in functional programming and the
> use of recursion; there most certainly is. But the way many texts
> introduce it IMO doesn't help at all to understand the elegance that can
> be achieved.
Indeed. Wh
Terry Reedy schreef op 7/08/2020 om 22:08:
On 8/7/2020 11:46 AM, Chris Angelico wrote:
My point is that doing Fibonacci recursively is arguably more elegant
while being materially worse at performance.
This is a common misconception. Linear iteration and tail recursion are
equivalent. The i
On Sat, 8 Aug 2020 at 03:46, Christian Seberino wrote:
> >> Readability of programming languages was measured
> >> using an objective method, and Python was one of
> >> the most readable.
>
> Do you have a source for this?
This question means you have not read at all my suggestions :-D
Anyway, th
>> Readability of programming languages was measured
>> using an objective method, and Python was one of
>> the most readable.
Do you have a source for this?
--
https://mail.python.org/mailman/listinfo/python-list
On 8/7/20 6:55 PM, Marco Sulla wrote:
> On Sat, 8 Aug 2020 at 00:28, Richard Damon wrote:
>> The really interesting part is that since Lisp programs manipulate lists
>> as data, and the program is just a list, Lisp programs have the
>> theoretical ability to edit themselves (assuming the implement
On Sat, 8 Aug 2020 at 00:28, Richard Damon wrote:
> The really interesting part is that since Lisp programs manipulate lists
> as data, and the program is just a list, Lisp programs have the
> theoretical ability to edit themselves (assuming the implementation give
> access to the list of the prog
berino just expressed a doubt about how a clear separation
> between a statement and an expression is quite desiderable in the
> "real" programming world. And I tried to explain it with the
> assignment operation, since a ton of programmers feel very frustrated
> abo
On 8/7/2020 11:55 AM, Marco Sulla wrote:
@Chris: note that "real" recursion in Python is not possible,
This is backwards. Python only does real recursion when one writes
recursive calls.
since there's no support for tail recursion.
I am pretty sure that what you mean by 'support' is to
e not students, they are experienced programmers. This may
explain why they usually can easily implement the recursive version,
but it does not really address why most of them have trouble with the
iterative version. :)
--
https://mail.python.org/mailman/listinfo/python-list
On 8/7/20 4:08 PM, Terry Reedy wrote:
> On 8/7/2020 11:46 AM, Chris Angelico wrote:
>
>> My point is that doing Fibonacci recursively is arguably more elegant
>> while being materially worse at performance.
>
> This is a common misconception. Linear iteration and tail recursion
> are equivalent.
On Sat, Aug 8, 2020 at 6:34 AM Terry Reedy wrote:
>
> On 8/7/2020 11:46 AM, Chris Angelico wrote:
>
> > My point is that doing Fibonacci recursively is arguably more elegant
> > while being materially worse at performance.
>
> This is a common misconception. Linear iteration and tail recursion ar
On Fri, 7 Aug 2020 at 22:35, Terry Reedy wrote:
> This is a common misconception. Linear iteration and tail recursion are
> equivalent. The issue is calculating values once versus multiple times.
> Here is the fast recursion equivalent to the fast iteration.
>
> def fib(n, pair=(1,0)):
> p
On Fri, 7 Aug 2020 at 19:41, Christian Seberino wrote:
> I think this is really significant point why more syntax does necessarily
> mean less readability.
I don't think so. Readability of programming languages was measured
using an objective method, and Python was one of the most readable.
The
On 2020-08-07 at 13:43:06 -0500,
Wyatt Biggs wrote:
> > It's also probably significantly slower, so you'd likely still want to
> > use the iterative version
>
> Generalizing this to the majority of recursive functions/methods, are
> their iterative counterparts more efficient? (I say "majority o
On 8/7/2020 11:46 AM, Chris Angelico wrote:
My point is that doing Fibonacci recursively is arguably more elegant
while being materially worse at performance.
This is a common misconception. Linear iteration and tail recursion are
equivalent. The issue is calculating values once versus mult
world. And I tried to explain it with the
> assignment operation, since a ton of programmers feel very frustrated
> about reading code of other programmers with assignment in an if
> statement. I'm quite sure that they thought, as I thought: "What do
> this?"
> Worse whe
On 2020-08-07 at 11:02:50 -0700,
Christian Seberino wrote:
> > In Lisp, your hammer is the list.
>
> > In, say, Java, your tool is classes and inheritance.
>
> And yet if Lisp or Java programmers were here they would say their
> languages //are// multi-paradigm too. For example, Lisp has the
>
en a statement and an expression is quite desiderable in the
"real" programming world. And I tried to explain it with the
assignment operation, since a ton of programmers feel very frustrated
about reading code of other programmers with assignment in an if
statement. I'm quite sure th
> It's also probably significantly slower, so you'd likely still want to
> use the iterative version
Generalizing this to the majority of recursive functions/methods, are their
iterative counterparts more efficient? (I say "majority of" because I've
personally encountered one or two recursive func
> In Lisp, your hammer is the list.
> In, say, Java, your tool is classes and inheritance.
And yet if Lisp or Java programmers were here they would say their
languages //are// multi-paradigm too. For example, Lisp has the
Common Lisp Object System (CLOS) and Java has the Vector class and so on
simultaneously open in your head.
>
> (defun dist-rad (lat1 lng1 lat2 lng2)
> (let* ((hlat (haversine (- lat2 lat1)))
> ;; Then there's the let vs. let* issue,
> ;; no big deal for experienced programmers
> ;; but not entirely easy to explain to a beginner.
>
On 8/7/20 12:52 PM, Marco Sulla wrote:
> About statement vs expression: maybe you, Richard and
> 2QdxY4RzWzUUiLuE, are right, maybe not. This is hard to say, since the
> official C documentation is not public and you have to pay a small fee
> to obtain it.
>
> Anyway, I said "in C, the assignment i
> Another point to consider is the ecosystem of your language. If you
> install Python, then you get basic math, I/O, a GUI toolkit, network
> libraries, ... In more "traditional" languages like C or Lisp, you get
> math and I/O, period. For everything else you need to hunt down a
> library.
Your iterative fib(x) code and comment was quite nice.
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, 7 Aug 2020 at 18:48, Chris Angelico wrote:
> Tail call optimization (there's no reason to restrict it to recursion
> alone) is something a Python implementation could choose to do, but
> the trouble is that full optimization tends to destroy traceback
> information
Indeed this is implemen
About statement vs expression: maybe you, Richard and
2QdxY4RzWzUUiLuE, are right, maybe not. This is hard to say, since the
official C documentation is not public and you have to pay a small fee
to obtain it.
Anyway, I said "in C, the assignment is a statement that can be used
in expression". You
On Sat, Aug 8, 2020 at 2:44 AM Richard Damon wrote:
>
> On 8/7/20 11:46 AM, Chris Angelico wrote:
> > My point is that doing Fibonacci recursively is arguably more elegant
> > while being materially worse at performance, but there are other
> > examples that are fundamentally recursive, are just a
On Sat, Aug 8, 2020 at 2:21 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2020-08-07 at 17:55:45 +0200,
> Marco Sulla wrote:
> > @Chris: note that "real" recursion in Python is not possible, since
> > there's no support for tail recursion. Maybe something similar can be
> > done using asyn
On 8/7/20 11:46 AM, Chris Angelico wrote:
> My point is that doing Fibonacci recursively is arguably more elegant
> while being materially worse at performance, but there are other
> examples that are fundamentally recursive, are just as elegant (merge
> sort: "fracture the array in half, sort each
On 8/7/20 11:55 AM, Marco Sulla wrote:
> Commonly, in imperative languages like C, you can write
>
> if (a = b) {...}
>
> This is allowed in C, even if a = b is not an expression, but an
> assignment statement. 99% of times you simply wrong and wanted:
But in C (and related languages) it IS an exp
On 2020-08-07 at 17:55:45 +0200,
Marco Sulla wrote:
> On Fri, 7 Aug 2020 at 17:14, Christian Seberino wrote:
> Commonly, in imperative languages like C, you can write
>
> if (a = b) {...}
>
> This is allowed in C, even if a = b is not an expression ...
In C, a = b *is* an expression. An ass
ntheses simultaneously open in your head.
(defun dist-rad (lat1 lng1 lat2 lng2)
(let* ((hlat (haversine (- lat2 lat1)))
;; Then there's the let vs. let* issue,
;; no big deal for experienced programmers
;; but not entirely easy to explain to a beginner.
;; On the other h
Am 06.08.20 um 17:13 schrieb Christian Seberino:
Python is my favorite language and the easiest to use in my opinion.
Lisp has a far simpler grammar and syntax. A beginner I think could
learn Lisp much faster than Python.
Therefore, it seems like Lisp *should* be easier to work with and more
On Fri, 7 Aug 2020 at 17:14, Christian Seberino wrote:
> This is an interesting observation. I've heard people say the fact that
> Python has both expressions and statements is a negative. (Lisp only
> has expressions.)
Commonly, in imperative languages like C, you can write
if (a = b) {...}
On Sat, Aug 8, 2020 at 1:38 AM Python wrote:
>
> On Fri, Aug 07, 2020 at 04:23:42PM +1000, Chris Angelico wrote:
> > On Fri, Aug 7, 2020 at 11:11 AM Python wrote:
> > > Pretty straightforward. Now try yourself to write the iterative
> > > version.
> >
> > It might look slightly better to a mathe
On Fri, Aug 07, 2020 at 04:23:42PM +1000, Chris Angelico wrote:
> On Fri, Aug 7, 2020 at 11:11 AM Python wrote:
> > Pretty straightforward. Now try yourself to write the iterative
> > version.
>
> It might look slightly better to a mathematician, but it's so
> abysmally inefficient (unless you a
> 1. Python mostly separates computation of values (expressions) from flow
> control and name binding (statements). When the latter are mixed with
> the former, most people restrict the mixing to a line or two.
This is an interesting observation. I've heard people say the fact that
Python ha
On Sat, Aug 8, 2020 at 1:06 AM Christian Seberino wrote:
>
>
> > ChrisA
>
> You're definitely an expert programmer.
>
Uhh thank you? I think? I'm not sure if you're complimenting me or
making some sort of joke relating to the code I posted, or if it's
actually nothing to do with me at all. Al
> ChrisA
You're definitely an expert programmer.
--
https://mail.python.org/mailman/listinfo/python-list
> If "the Python way" seems simpler to you than "the Lisp way,"
> or iteration seems simpler to you than recursion, then so be it. Other
> languages and other programmers are different.
I think this is so true. I've had similar conversations with Lisp fans
and it has confused me at times why the
simpler syntax arises from the fact that
there's basically one data structure: a list.
In general, the one data structure is a tree*, skewed by being smashed
into a linked list. Replaced 'list' with 'skewed tree' in what you say
below, and I think you explain well th
On 8/6/2020 11:13 AM, Christian Seberino wrote:
Python is my favorite language and the easiest to use in my opinion.
Lisp has a far simpler grammar and syntax. A beginner I think could
learn Lisp much faster than Python.
Therefore, it seems like Lisp *should* be easier to work with and more
On Fri, Aug 7, 2020 at 11:11 AM Python wrote:
> Not necessarily. Some problems very naturally lend themselves to
> recursive solutions. Fibonacci's sequence is one.
>
> #!/usr/bin/python
>
> def fib(x):
> if x < 1:
> raise "arg must be >= 1"
> if x == 1:
> return 0
>
On 2020-08-06 at 20:07:05 -0700,
Christian Seberino wrote:
> Some problems are well suited to recursion but perhaps //most//
> problems are better suited to iteration?
> Maybe the spread is 10% vs 90%?
Citation needed?
> Therefore in general more often the Python way seems simpler than Lisp?
Some problems are well suited to recursion but perhaps //most// problems are
better suited to iteration?
Maybe the spread is 10% vs 90%?
Therefore in general more often the Python way seems simpler than Lisp?
--
https://mail.python.org/mailman/listinfo/python-list
On 2020-08-06 at 16:08:29 -0700,
Christian Seberino wrote:
> > Trying to maintain that recursive list of unclosed lists in your
> > brain is fun. It stretches the brain in interesting ways. I was
> > way into Lisp at one point, including writing several Lisp
> > interpreters (that simple structur
On Thu, Aug 06, 2020 at 04:08:29PM -0700, Christian Seberino wrote:
> > Trying to maintain that recursive list of unclosed lists in your
> > brain is fun. It stretches the brain in interesting ways. I was
> > way into Lisp at one point, including writing several Lisp
> > interpreters (that simple s
> Trying to maintain that recursive list of unclosed lists in your
> brain is fun. It stretches the brain in interesting ways. I was
> way into Lisp at one point, including writing several Lisp
> interpreters (that simple structure makes Lisp very easy to
> implement). But I never found Lisp code v
On 8/6/20 4:07 PM, 2qdxy4rzwzuui...@potatochowder.com wrote:
> for (index, value) in enumerate(this_list):
> this_list[index] = 2 * value
>
> Or:
>
> for index in range(len(this_list)):
> this_list[index] *= 2
>
> (But I tend to avoid that, though, because I can never rememb
On 2020-08-07 at 05:22:53 +1000,
Chris Angelico wrote:
> On Fri, Aug 7, 2020 at 5:10 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> One thing worth noting is that your mental pseudo-code is affected by
> the languages you're comfortable with. You said:
>
> > create a new list in which each va
On Fri, Aug 7, 2020 at 5:10 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> I would say that expressiveness is how *directly* you can translate your
> ideas into code, and how *directly* some one else can see your original
> idea by reading your code.
Yep, how directly or how accurately.
> So
On 2020-08-07 at 04:00:34 +1000,
Regarding "Re: How explain why Python is easier/nicer than Lisp which has a
simpler grammar/syntax?,"
Chris Angelico wrote:
> On Fri, Aug 7, 2020 at 2:36 AM Christian Seberino wrote:
> >
> > On Thursday, August 6, 2020 at 10:52:00 AM UT
Christian Seberino writes:
> Python is my favorite language and the easiest to use in my opinion.
>
> Lisp has a far simpler grammar and syntax. A beginner I think could
> learn Lisp much faster than Python.
>
> Therefore, it seems like Lisp *should* be easier to work with and more
> readable.
On Fri, Aug 7, 2020 at 2:36 AM Christian Seberino wrote:
>
> On Thursday, August 6, 2020 at 10:52:00 AM UTC-5, Chris Angelico wrote:
> > The point of learning a
> > language isn't that you can take a piece of pre-existing code and
> > figure out what it'll do, step by step; the point is to be able
On Thursday, August 6, 2020 at 10:52:00 AM UTC-5, Chris Angelico wrote:
> The point of learning a
> language isn't that you can take a piece of pre-existing code and
> figure out what it'll do, step by step; the point is to be able to
> encode your intentions in that language, and to read the code
On Fri, Aug 7, 2020 at 1:16 AM Christian Seberino wrote:
>
> Python is my favorite language and the easiest to use in my opinion.
>
> Lisp has a far simpler grammar and syntax. A beginner I think could
> learn Lisp much faster than Python.
>
> Therefore, it seems like Lisp *should* be easier to
Python is my favorite language and the easiest to use in my opinion.
Lisp has a far simpler grammar and syntax. A beginner I think could
learn Lisp much faster than Python.
Therefore, it seems like Lisp *should* be easier to work with and more
readable. I don't feel like it is easier to use b
在 2016年9月20日星期二 UTC-4下午3:11:27，Terry Reedy写道：
> On 9/20/2016 9:12 AM, Peter Otten wrote:
>
> >> 在 2016年9月20日星期二 UTC-4上午8:17:13，BartC写道：
> >>> On 20/09/2016 13:12, 38016226...@gmail.com wrote:
> >>> d = {}
> >>> keys = range(256)
> >>> vals = map(chr, keys)
> >>> map(operator.setite
Nobody wrote:
> On Tue, 20 Sep 2016 15:12:39 +0200, Peter Otten wrote:
>
>> because they don't build lists only to throw them away.
>
> The lists could have been avoided by using iterators, e.g.
>
> import itertools as it
> keys = xrange(256)
> vals = it.imap(chr, keys)
> max(it.imap(operator.s
On Tue, 20 Sep 2016 15:12:39 +0200, Peter Otten wrote:
> because they don't build lists only to throw them away.
The lists could have been avoided by using iterators, e.g.
import itertools as it
keys = xrange(256)
vals = it.imap(chr, keys)
max(it.imap(operator.setitem, it.repeat(d), keys, vals))
On 9/20/2016 9:12 AM, Peter Otten wrote:
在 2016年9月20日星期二 UTC-4上午8:17:13，BartC写道：
On 20/09/2016 13:12, 38016226...@gmail.com wrote:
d = {}
keys = range(256)
vals = map(chr, keys)
map(operator.setitem, [d]*len(keys), keys, vals)
It is from python library. What does [d]*len(keys) mean?
d is the
在 2016年9月20日星期二 UTC-4上午9:13:35，Peter Otten写道：
> 38016226...@gmail.com wrote:
>
> > 在 2016年9月20日星期二 UTC-4上午8:17:13，BartC写道：
> >> On 20/09/2016 13:12, 38016226...@gmail.com wrote:
> >> d = {}
> >> keys = range(256)
> >> vals = map(chr, keys)
> >> map(operator.setitem, [d]*len(key
38016226...@gmail.com wrote:
> 在 2016年9月20日星期二 UTC-4上午8:17:13，BartC写道：
>> On 20/09/2016 13:12, 38016226...@gmail.com wrote:
>> d = {}
>> keys = range(256)
>> vals = map(chr, keys)
>> map(operator.setitem, [d]*len(keys), keys, vals)
>> >
>> > It is from python library. What does
在 2016年9月20日星期二 UTC-4上午8:17:13，BartC写道：
> On 20/09/2016 13:12, 38016226...@gmail.com wrote:
> d = {}
> keys = range(256)
> vals = map(chr, keys)
> map(operator.setitem, [d]*len(keys), keys, vals)
> >
> > It is from python library. What does [d]*len(keys) mean?
> > d is the name
On 20/09/2016 13:12, 38016226...@gmail.com wrote:
d = {}
keys = range(256)
vals = map(chr, keys)
map(operator.setitem, [d]*len(keys), keys, vals)
It is from python library. What does [d]*len(keys) mean?
d is the name of dict but put d in [] really confused me.
if len(keys) is 5 then [d]*5 is
>>> d = {}
>>> keys = range(256)
>>> vals = map(chr, keys)
>>> map(operator.setitem, [d]*len(keys), keys, vals)
It is from python library. What does [d]*len(keys) mean?
d is the name of dict but put d in [] really confused me.
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, Jan 19, 2016 at 4:00 AM, Ian Kelly wrote:
>> Armed with that information, you should be able to track down what's
>> going on. It's curious, though, that you have a callable subclass of
>> module bound to the name int. Very curious indeed.
>
> What makes you think that it's a callable subc
On Mon, Jan 18, 2016, at 11:51, Chris Angelico wrote:
> Armed with that information, you should be able to track down what's
> going on. It's curious, though, that you have a callable subclass of
> module bound to the name int. Very curious indeed.
He hasn't tried calling it. And there's no reason
On Mon, Jan 18, 2016 at 9:51 AM, Chris Angelico wrote:
> On Tue, Jan 19, 2016 at 3:28 AM, Charles T. Smith
>> Okay, I think I understand it now:
>>
>> (PDB)type (int)
>>
>>
>> (PDB)type (float)
>>
>
> And that's pretty strong evidence right there! So the next question
> is... what got imported u
On Tue, Jan 19, 2016 at 3:28 AM, Charles T. Smith
wrote:
> On Tue, 19 Jan 2016 03:19:59 +1100, Chris Angelico wrote:
>> Possibility #1: 'int' has been rebound.
>>
>> Possibility #2: 'type' has been rebound.
>>
>> I'd check them in that order.
>>
>> ChrisA
>
>
> But:
>
> (PDB)p 5 + 0
> 5
That show
On Tue, 19 Jan 2016 03:19:59 +1100, Chris Angelico wrote:
> On Tue, Jan 19, 2016 at 3:11 AM, Charles T. Smith
> wrote:
>> $ python
>> Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) [GCC 4.4.3] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
> type(0) is i
On Tue, Jan 19, 2016 at 3:11 AM, Charles T. Smith
wrote:
> $ python
> Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
> [GCC 4.4.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
type(0) is int
> True
> ...
> (PDB)type(0) is int
> False
> (PDB)type(1) is i
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> type(0) is int
True
...
(PDB)type(0) is int
False
(PDB)type(1) is int
False
(PDB)p 5 + 0
5
(PDB)class c (object): pass
(PDB)type (c()) is c
T
Apologies for self-replying,
On 01/12/15 22:34, Erik wrote:
what you're asking for is that
the *container* object whose element is being assigned to is first
queried as to whether it will accept a mutated element being assigned to
it before that element is mutated.
What I said above is rubbis
On 12/1/2015 4:36 PM, Denis McMahon wrote:
On Tue, 01 Dec 2015 16:18:49 -0500, Terry Reedy wrote:
On 12/1/2015 3:32 PM, Denis McMahon wrote:
On Tue, 01 Dec 2015 03:32:31 +, MRAB wrote:
In the case of:
tup[1] += [6, 7]
what it's trying to do is:
tup[1] = tup[1].__iadd__([
On 01/12/15 21:37, Denis McMahon wrote:
The assignment succeeds. That's imo a bug. If it's a TypeError to try and
assign a value to tup[1], then tup[1] should not allow the mutated list
to be assigned.
Nothing got assigned.
That original list object remains in that slot. However, it has been
On Tue, 01 Dec 2015 14:44:38 -0600, Ian Kelly wrote:
> On Tue, Dec 1, 2015 at 2:32 PM, Denis McMahon
> wrote:
>> On Tue, 01 Dec 2015 03:32:31 +, MRAB wrote:
>>
>>> In the case of:
>>>
>>> tup[1] += [6, 7]
>>>
>>> what it's trying to do is:
>>>
>>> tup[1] = tup[1].__iadd__([6, 7])
>>
On Tue, 01 Dec 2015 16:18:49 -0500, Terry Reedy wrote:
> On 12/1/2015 3:32 PM, Denis McMahon wrote:
>> On Tue, 01 Dec 2015 03:32:31 +, MRAB wrote:
>>
>>> In the case of:
>>>
>>> tup[1] += [6, 7]
>>>
>>> what it's trying to do is:
>>>
>>> tup[1] = tup[1].__iadd__([6, 7])
>>>
>>> tup
On 12/1/2015 3:32 PM, Denis McMahon wrote:
On Tue, 01 Dec 2015 03:32:31 +, MRAB wrote:
In the case of:
tup[1] += [6, 7]
what it's trying to do is:
tup[1] = tup[1].__iadd__([6, 7])
tup[1] refers to a list, and the __iadd__ method _does_ mutate it, but
then Python tries to put
On Tue, Dec 1, 2015 at 2:32 PM, Denis McMahon wrote:
> On Tue, 01 Dec 2015 03:32:31 +, MRAB wrote:
>
>> In the case of:
>>
>> tup[1] += [6, 7]
>>
>> what it's trying to do is:
>>
>> tup[1] = tup[1].__iadd__([6, 7])
>>
>> tup[1] refers to a list, and the __iadd__ method _does_ mutate
On Tue, 01 Dec 2015 03:32:31 +, MRAB wrote:
> In the case of:
>
> tup[1] += [6, 7]
>
> what it's trying to do is:
>
> tup[1] = tup[1].__iadd__([6, 7])
>
> tup[1] refers to a list, and the __iadd__ method _does_ mutate it, but
> then Python tries to put the result that the method
On 2015-12-01 02:14, fl wrote:
On Wednesday, June 24, 2015 at 8:17:08 PM UTC-4, Chris Angelico wrote:
On Thu, Jun 25, 2015 at 9:52 AM, fl wrote:
> The reason is that list implements __iadd__ like this (except in C, not
Python):
>
> class List:
> def __iadd__(self, other):
> self.ex
On Wednesday, June 24, 2015 at 8:17:08 PM UTC-4, Chris Angelico wrote:
> On Thu, Jun 25, 2015 at 9:52 AM, fl wrote:
> > The reason is that list implements __iadd__ like this (except in C, not
> > Python):
> >
> > class List:
> > def __iadd__(self, other):
> > self.extend(other)
> >
fl writes:
> Hi,
>
> I cannot reason out why the code:
>
> def mpl():
> return [lambda x : i * x for i in range(4)]
>
> print [m(2) for m in mpl()]
> /
>
> has result:
>
> [6, 6, 6, 6]
The "i" in your lambda definition is a variable reference which
is not dereferenced (
On Wed, Nov 18, 2015 at 5:05 PM, fl wrote:
> Hi,
>
> I cannot reason out why the code:
>
> def mpl():
> return [lambda x : i * x for i in range(4)]
>
> print [m(2) for m in mpl()]
> /
>
> has result:
>
> [6, 6, 6, 6]
>
>
> I have tried to simplify the above code to an easy und
Hi,
I cannot reason out why the code:
def mpl():
return [lambda x : i * x for i in range(4)]
print [m(2) for m in mpl()]
/
has result:
[6, 6, 6, 6]
I have tried to simplify the above code to an easy understanding form,
but fails. Either the modified code does not work
t it is
in the above line. Can you explain it to me?
Its just a variable whose value isn't used in this specific expression, you
could use 'x', 'y', or any other valid variable
name there and it should work.
--
Atnakus Arzah
When in doubt, have a cookie!
--
https://mail.python.org/mailman/listinfo/python-list
On 06/25/2015 06:07 PM, fl wrote:
Hi,
I read Ned's tutorial on Python. It is very interesting. On its last
example, I cannot understand the '_' in:
board=[[0]*8 for _ in range(8)]
I know '_' is the precious answer, but it is still unclear what it is
in the above
ge(8)]
I know '_' is the precious answer, but it is still unclear what it is
in the above line. Can you explain it to me?
Thanks,
Lots of people could carry on explaining things to you, but you don't
appear to be making any attempt to do some research before posing your
question
>
> > board=[[0]*8 for _ in range(8)]
> >
> >
> > I know '_' is the precious answer, but it is still unclear what it is
> > in the above line. Can you explain it to me?
> >
> >
> > Thanks,
> >
>
> Lots of people could carry
is the precious answer, but it is still unclear what it is
> in the above line. Can you explain it to me?
'_' is the previous answer ONLY when using the read-eval-print-loop interpreter.
Here, it is the "name" of a variable; since we don't care about the particular
nam
On 26/06/2015 02:07, fl wrote:
Hi,
I read Ned's tutorial on Python. It is very interesting. On its last
example, I cannot understand the '_' in:
board=[[0]*8 for _ in range(8)]
I know '_' is the precious answer, but it is still unclear what it is
in the above li
Hi,
I read Ned's tutorial on Python. It is very interesting. On its last
example, I cannot understand the '_' in:
board=[[0]*8 for _ in range(8)]
I know '_' is the precious answer, but it is still unclear what it is
in the above line. Can you explain it t
fl writes:
> aa=[1, 2, 3].remove(2)
>
> I don't know where the result goes. Could you help me on the question?
That method modifies the list and returns None (or raises an exception).
Get a hold on the list first:
aa=[1, 2, 3]
*Then* call the method. Just call the method, do not try to store t
1 - 100 of 504 matches
Mail list logo
